OpenID connect (OIDC) is a simple extension to the OAuth2 protocol, which lets a server include more information about the authenticated user (canonical ID, username, email, etc).

At the very simple level, this lets you quickly populate a new user account without making additional requests. However, since these ID tokens are signed, it lets you do a whole lot more.

For example, you can pass these tokens around when making API requests in a modern micro service environment – each micro service will be able to securely authenticate the user that is making the request independently.

Known has had OAuth support (client and server) for a while now, but recently I’ve extended both to support OIDC.

The client will validate and use OIDC tokens when authenticating against a server, and the Known OAuth server will now generate OIDC tokens for users authenticating against a Known OAuth2 application.

Requesting OIDC from the client

OIDC tokens are not automatically provided, so you need to request them. Do this by adding openid to your list of scopes. I also suggest you add email and profile to your scopes too, so you get some actually useful information about the authenticating user.

You’ll also need to provide a URL for where to get the public key for the issuing server. This isn’t terribly slick, but I intend to improve this going forward with some nice auto discovery.

» Visit the project on Github...

Issuing OIDC from the server

All new applications will have the necessary information to start issuing OIDC tokens.

A new key pair will automatically be generated, and you’ll be able to get public key information from:

» Visit the project on Github...

I was recently trying to develop some Known schema changes, and had the need to start kicking about Known in a Postgres environment.

Known supports Postgres out of the box, but I admit it’s a less trodden path. I don’t routinely use Postgres (I tend to favour mysql/mariadb, purely because that’s what I’m used to), and it’s usually a pain to switch environments.

I previously built a docker development environment, so I took the obvious (and as it turned out trivial) next step to build a Postgres version.


  • Download and install docker
  • Add this docker image to known using composer composer require mapkyca/mapkyca-known-docker-postgres --dev

This will create a docker environment in /vendor/mapkyca/mapkyca-known-docker-postgres/


  • cd /vendor/mapkyca/mapkyca-known-docker-postgres/
  • docker-compose up
  • Point your browser at localhost:8089 and install in the usual way

» Visit the project on Github...

Even though we’re all under house arrest, work never stops!

However, because of all this excitement, I’ve had to switch about on machines and development environments a lot recently.

Previously, I’ve used my Known vagrant build to do development, but that started to prove a little bit heavy on a number of setups I’ve been using. So, since I’ve been playing with docker more recently, I thought it’d be nice to have a development container folks could use to quickly get up and running.

I’ve created a docker image that you can use in order to set up a quick development environment for your Known, and is installable via composer.


  • Download and install docker
  • Add this docker image to known using composer composer require mapkyca/mapkyca-known-docker --dev

This will create a docker environment in /vendor/mapkyca/mapkyca-known-docker/


  • cd /vendor/mapkyca/mapkyca-known-docker/
  • docker-compose up
  • Point your browser at localhost:8088 and install in the usual way

Data storage

Files you upload will be stored in your Known install’s “Uploads” directory.

Your database will be stored in /vendor/mapkyca/mapkyca-known-docker/db/run/.


This is designed to be used for temporary development, not production. I make no promises as to what happens to the database directory when doing composer updates.

If you care, back this up regularly!

» Visit the project on Github...