Very quick update, as part of some paid Known development, I’ve made a few important updates to the Known OAuth2 client.
Essentially, this is to make it work better with non-OIDC (Open ID Connect) clients, and with those servers that don’t support Owner Info endpoints.
Folks following the GitHub HEAD release of Known should get this in their next composer update, but for other folks I’ll build a new unofficial release soon.
Have a great weekend folks!
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.
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...
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/
It is the second time in as many days that I’m having to log into things and change passwords because of some less-than smart design decisions various web companies made when implementing their password database (looking at you Linkedin and Last.FM).
While these companies have clearly made a dangerous snafu, lets not be overly harsh on them. There but for the grace of god go all software developers. The real problem is passwords, and until we find something better, this kind of thing will keep happening.
Lets look at it from a UX viewpoint as well a security one for a moment, because they’re both linked. People, myself included, are phenomenally bad at creating secure passwords and remembering them. Predictably enough, this results in the vast majority of users using one memorable (but as a result easily guessable) password for everything, and/or writing all their passwords down somewhere… both things that are a bad idea from a security point of view and often elicit derisive snorts from security professionals clearly blessed with an eidetic memory.
Computers should adapt to humans, not the other way round. Isn’t it time we stopped wasting time trying to patch a clearly broken system and build something else?
This is of course much easier said than done, and the two current alternatives to username/password authentication available – OpenID and OAuth – are not without their issues.
OpenID is nice and decentralised, but the UX is just awful. Sign in with a URL? Try explaining that one over the phone to your mum.
OAuth has the benefit of being super super easy for the user (one or two mouse clicks to log in), so long as you’ve got an account with a given site’s blessed identity broker (for all practical purposes either Google, Facebook or Twitter). This model nudges towards a centralised identity model which I find very uncomfortable.
This centralisation raises new issues of catastrophic single points of failure. Not only do you have the issue of the service being a prime target for crackers, you also have a far more insidious and arguably more likely problem, basically, what happens when the identity broker you use for your 1000s of accounts goes out of business?
Not to mention, all three of the main identity brokers still fundamentally identify you with a username and password. Google and Facebook have added second layer authentication to their accounts, but Twitter is yet to implement anything (so if you have a twitter account and use it for authentication anywhere make sure your password is really really good).
So, what can we do to make this better?
Myself, I’d like to move to some sort of two factor authentication (combining something you have with something you know), at least for really important accounts. More and more people have mobile phones so perhaps something similar to the Google authenticator model or SMS code authentication for new machine sign-in would be a start.
Whatever we use, it needs to be decentralised, secure, and fundamentally easy for people to use. Because if whatever fancy solution we come up with provides a barrier between the user and what they want to do, it will be useless. People will just work out ways of circumventing the security in order to get things done, or simply not use the service at all.
Today, the most secure password-protected system you can ever build can be defeated by one forgetful user and a post-it note.
