Question

We're looking into adding authentication to a range of APIs that we are about to develop. The solution is entirely fluid as it currently stands, but the basic premise is that there is one API layer that the customer interfaces with, and several APIs behind that that this initial layer delegates to.

Part of the proposed diagram contains a single sign on server that enables users to authentication once and use the token generated to gain access to all of the available resources.

The more I read into this, the more bizarre my understanding of how oAuth is going to fit this model is. From what i can see, oAuth simply supports the authentication of client applications that the user wishes to give some permissions to.

Our aim is to make a simple login functionality, but in a Single Sign On fashion. Is oAuth a good fit for this or is there a more appropriate solution for delegating authentication trust to a single server for multiple applications?

Was it helpful?

Solution

OAuth is an authorization protocol, not an authentication one.

At some point in the process a user has to authenticate to the authorization server to prove that she's allowed to authorize access to the protected resource for your app.

An authentication service can be built on top of oauth2 because the protected resource can be information about the user that identifies him uniquely, but in order to do that you need a good understanding of OAuth and why it isn't fit for autentication out of the box.

Fortunately, the guys at OpenID Connect already did the hard work for you.

Assumming when you said OAuth you actually meant OpenID, I'd say yes, using it for an SSO scheme is a very good idea: it works well, is well proven and scales a lot.

It's also quite easy to integrate it into almost anything.

Licensed under: CC-BY-SA with attribution
scroll top