It’s been a little while since I’ve done this, but I’ve updated the “official” Known build to the latest version.

This fixes a bunch of issues since the 1.0.0 release last year. Much of which is back end and API related, but there’s still plenty to be getting stuck in to. I’ve largely been setting the groundwork for future development, but there’s a lot that’s moved on since that release, so it’s good to encourage people to get the latest code!

For a start, there’s functional OAuth and OpenID Connect support built in.

I’ve done a fair amount to improve stability of the installer, as well as do some fairly important improvements to the underlaying data model.

Time permitting, I hope that the next release will be a little more front end focussed. Splitting off templates into their own repository, updating themes and doing more work to make the API more consumable.

Of course, as per usual, back up your data and database before upgrading!

Go get Known here!

During the work I’ve previously done around OpenID Connect and Federation, I ran into the need to be able to mutate Entities.

Every Entity in Known has a type, and internally this corresponds to a PHP Class when loaded from data storage. Each Class has its own abilities and methods, and in general you’re not going to want to turn one into another.

However, I did.

This occurred when a User (which corresponds to a User) object logs in to a site after they’ve already used the federated API (which would create a RemoteUser object internally).

When that occurs, we want to convert the RemoteUser account into a full fat User. We can’t simply delete and recreate the user as that would lose all their history, and remove any posts they have made, etc.

So, we need a mechanism to mutate them.

This should be safe, since RemoteUser is a child of User, so they’re not vastly different things.

So, as of recent builds of Known, RemoteUser implements the interface Mutable, which defines a method mutate that accepts a class name to mutate to. On success it’ll return the newly mutated object. This object will have the same ID and data.

For convenience, there’s also a Trait Mutate that you can mix in, which provides a reference implementation of this interface. That implementation will check to see that the class you’re wanting to mutate and the class you’re wanting to mutate to are both related, and if so will perform the necessary incantations on the database.

Useful tool, but “with great power…” etc.

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:

https://mysite.com/oauth2/CLIENTID/key/

» Visit the project on Github...