OAuth2 based SSO

Question

Our project consists several sub application, and we are looking for a solution to implement SSO to avoid the authentication for each sub application.

Suppose this is the structure of our project:

authentication server(call it AS or IdP or something else)
order-system
product-system
data-analysis-system
.......

And we found that there are a lot of articles of "SSO implemented based on OAuth2" like this.

In that article, we prefer to the SAML strategy because it is simple and clear, however there are some limitations for native application, then we focused on the OAuth2.

This is the work flow:

1 Rules in OAuth2

Resource Server (SP) – this is the web-server you are trying to access information on.

Client – this is how the user is interacting with the Resource Server. This could be a browser-based web app, a native mobile app, a desktop app, a server-side app.

Authorization Server (Idp) – this is the server that owns the user identities and credentials. It's who the user actually authenticates and authorizes with.

Take OctoDroid as an example, the rules are very clear:

Client: OctoDroid
Idp: GitHub
SP: Github
User: one who use OctoDroid application.

The workflow is that OctoDroid(Client) ask you(User) to login and grant permissions through Github(Idp) to get the resources(repos,issues) from Github(SP).

But in our application, what exactly can each sub-system treated? a SP or a Client ?

If treated as a SP, is web browser the Client? I always thought that a Client should be an application. Also the sub-system validate the access_token through Idp for each request and then return the related resource, will this increase the pressure to the Idp?

If treated as a Client, who is the SP?

2 Rules in application

For a same user, he may have different rules in different sub-systems, for example, he can read/write all the orders from order-system, but he can not access the product-system. Then where should the rules configuration happen? In the Idp or in each sub-system?

3 Session Synchronization

For a typical SSO system, when user login(through Idp), all sub-system should login, when user logout , all sub-system should logout.

However in the above OAuth2 workflow, it seems that different SPs or Clients are independent. When you logout from OctoDroid, you can still use OpenHub once you have login. In this case, it seems like OAuth2 is different from SSO, how can they work together?

4 Idp connect to another Idp

In our application, In addition to the basic username and password login, the authentication server should provide login from google,facebook and other CAS providers too. Is this possible?

---

BTW, I am not sure if I have made myself clear enough, if not, ask me in the comments.

Answer 1

Thought I'd join in the discussion with some real world feedback on the kind of patterns that tend to work best. A lot of the OAuth jargon is not helpful and confuses people. Mark Kavindu's as the accepted answer though ...

Q1. SUBSYSTEMS

Software producing companies often want to build a platform of UIs and APIs. Most of the time, in your terminology, the UIs are the clients (they get tokens) and the APIs are the subsystems (they receive tokens). There are some exceptions such as back end clients but these tend to be secondary.

SAML is an old technology that was used by server side web apps, and is still used for federated logins. These days most companies want to build mobile apps and Javascript based apps, for which OAuth 2.x and Open Id Connect are a better fit - with many libraries - as Kavindu says.

Q2. RULES

One option here is to manage rules in the Authorization Server. For example you can use OAuth custom scopes as high level privileges, which then get added to access tokens and read by APIs:

• Order scope means you can perform Order related operations
• Product + Write scopes mean you can update the Products system

This may be fine for simple apps. For more complex apps it does not scale well, and there is a risk that scopes / claims for the Order API start adversely impacting the Products API.

More complex rules belong in your APIs, where they are easier to manage over time. This typically involves looking up the user from the access token in the subsystem's own data.

My personal preference is to use a Claims Based Architecture to work best for enforcing rules. If interested in this approach, see my blog posts below:

• User Data Management
• API Claims Based Authorization

Q3. SESSION SYNCHRONIZATION

Sometimes this is an area where OAuth based systems do not behave the way stakeholders expect, and people just need to be educated about the limitations of the technology. End users will not care if single log out works and you will not fail security reviews.

As an example, on a mobile device, logging out of a Browser UI will not log you out of a Mobile UI. The Mobile UI will continue to use a short lived access token but the user will be prompted to login again when the access token expires - perhaps 30 minutes later.

Q4. FEDERATION

Most Authorization Servers can federate to multiple Identity Providers to support multiple types of login. In the corporate world this often uses SAML 2.0 as a protocol. Which providers you allow often depends on the type of assets your subsystems deal with:

• For corporate assets you would not allow a user to sign in with their Facebook account
• For personal assets this might be fine

It is often a good technical goal to deal with multiple identity providers within the Authorization Server. Your UIs and APIs then only need to interface with the Authorization Server and its tokens, which reduces complexity.