I've been on a fact finding mission to discover more about OAuth and OpenID Connect.
OAuth was originally created to enable secure delegated access. It allows a user to authorise the source application (the client) to access their data stored in another application. For example, perhaps the client website needs to access a user's Facebook profile information, or their GMail contacts list.
The authorisation process sees the user redirected to a page on the destination site, where they click a button to agree to the client site having access to a subset of their data.
The destination site will then redirect the user back to the client site, with an authorisation token.
The client site can send this authorisation token (together with a key/secret) to an end-point on the destination site using a secure channel (i.e. server to server communication - known as back channel), which will provide the client site with a short-life access token, which can be used to make API calls on the destination service. Thus, delegated access to the user's data, without the need to share passwords.
I believe there is also a method which avoids the back channel communication (i.e. to turn the authorisation token in to an access token), for where a web application has no back-end component. However, this won't apply to me - so I haven't looked at it in detail.
If the user decides they'd rather the client application no longer has access to their data, the destination service will usually give them a method for revoking access (marking the authorisation token as invalid - preventing the client application from requesting further access tokens).
If like me, you started looking in to OAuth from the perspective of authentication and identity management, rather than authorisation - you might be thinking how does this even help?
This is where OpenID Connect comes in.
Originally, service providers added their own bespoke identity management layer to OAuth. But, nothing was standardised.
To standardise things, along came OpenID Connect - a layer on top of OAuth, which provides identity management.
The user's identity is provided by way of a JSON Web Token (JWT) - which asserts the identity of the user (the subject), and defines the issuing authority (and who the token was generated for). Tokens are digitally signed, so their authenticity can (and definitely should!) be verified by the recipient. Optionally, they can be encrypted for confidentiality purposes.
The token contains basic information which can be used to identify the user. However, the client can also request an access token, which will enable them to connect to an endpoint to fetch further information about the user/subject.
In a nutshell, that's a one page summary of my understanding of what OAuth does (and more importantly, doesn't) do - and how OpenID Connect plugs the identity management gap that exists with OAuth on its own. If I've misunderstood anything - feedback would definitely be appreciated.
Now to research further and get to the stage where I have a working demo - to help understand further.
Comments
Post a Comment