5

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?

christopher
  • 153
  • 4
  • OAuth2 is commonly used for securing rest services. There are some good libraries if you don't mind locking into a company or tech like Auth0 for example. It can be daunting to add to your services but once in place it can easy to auth with accounts from google, salesforce.com, and many many more. This is a comment as its not a full write-up, just something get you rolling forward. Scribejava is a good library to review as well if you are using Java. I can write this up more formally next week if you find this information starting to be useful. – Tim Cederquist Aug 26 '16 at 12:59

1 Answers1

1

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.

GnP
  • 169
  • 4
  • Hi there. This matches very closely to the solution that I have developed over the past few days. We have an Authorization server that exposes an endpoint that gives User details. This is treated as a resource that can be accessed if a user is authenticated but not authorized. They then use the authorities (we're using Spring) provided by the Spring OAuth server to determine whether they are authorised to do a thing (based on the permissions the client has and the user, if we're going with a password flow). – christopher Aug 26 '16 at 22:12
  • Great! Be sure to read [rfc6819](https://tools.ietf.org/html/rfc6819), particularly section 4.4.1 if you're using the code flow, which is the most common for authentication. – GnP Aug 26 '16 at 23:00