OAuth2 based SSO

user_306719 0
Viewed 10048

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:

enter image description here

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.

oauth-2.0 openid-connect single-sign-on
3 Answers

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:

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.

user_90198850

If you are building something new, then go ahead with OAuth 2.0. Compared to SAML, it is user friendly (ie- JSON based) and also modern. Besides there are many resources to help you out (ie- libraries and IDP adaptations). One more thing, since you want authentication, you should use OpenID Connect (spec). Well think about that as a simple extension built on OAuth 2.0.

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

OAuth 2.0 define few different application types (read). Going with your explanation, there are few of them in your system - web applications & native apps (may be mobile). If this is the case,

  • IDP - Your identity server
  • client - All the applications you develop
  • User agent - Browser used to activate OAuth flow
  • End user - Users of the systems.

And the resource server (SP) can be the back-end of each of these applications. Or it could be a common back-end service. But in any case it must be protected by OAuth tokens obtained by each of the client.

The token introspection (spec - rfc7662) define how you can validate tokens from the resource server. About the load on IDP, well it all depends on your scaling of the deployment.

2 Rules in application

So now we come to OpenID Connect. It define the ID token, which communicate your client about authenticated state of the end user. And it comes in a form of a JWT. And good thing about JWT is (apart from being JSON), it can have custom claims. The spec supports this (Additional Claims). So in your IDP, you will have to configure roles/user groups/permission and communicate this in ID Token to the clients.

3 Session Synchronization

IDPs use browser sessions to provide your clients SSO behaviour. When you login in to one client, your IDP creates a session. So when the end user use another client, IDP can check already logged in state, ask for missing permission and complete the login flow issuing required tokens.

OpenID Connect comes with session management spec (source) which provides your client a mechanism to verify changes in this session. Check with your choice of IDP on support for this.

4 Idp connect to another Idp

This is something out of scope of OAuth2.0 ecosystem. SAML has SAML federation which does this (note - I am not a SAML expert). And different identity providers have their own solutions (ex:- WSO2 bring your own identity). Such user provisioning depends on your requirements as well as IDP capabilities. But as I said it is out of scope for OAuth.

Note -About 4th question, if your IDP supports and if you are fine with, you can accept tokens issued by third party (ie- Google, Facebook) to authenticate users to the apps. This can be done on top of OpenID Connect. Furthermore, there exist SCIM (resources) which allows to query user data across different identity providers.

user_31970550

You have a lot of questions.

Questions Part 1

  • 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?
  • If treated as a Client, who is the SP?

I think these questions are related to : OAuth 2.0 four roles

Oauth2 Roles

Let's start with this classic flow diagram:

oauth2 flow

You can use these rules to determine what role your applications have:

  • Client

    • Moderns web (react, angular, vue, linkstart, etc) and mobile apps(android/ios). In general way, any piece of software who needs data from another piece of software could be a client. Commonly the client is a web and the requested data is an http api rest but the concept could apply to legacy (server rendering apps) or future apps (robots in a mall)

  • Resource Server

    • Http Rest Api. Keep it simple!! we are talking about an api developed in some backend language (java, python, nodejs, etc) consumable from Postman, Soapui, curl, javascript, etc

  • Authorization Server

    • Application which is in charge of token generations and more features related to the security of your applications

Questions Part 2

  • Then where should the rules configuration happen? In the Idp or in each sub-system?
  • 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?

Authentication and Authorization platforms

At this point you know about jwt tokens, user/password, users table, etc

But you need to ensure that a user with "guest" role cannot execute a DELETE invocation to an api rest endpoint /user/100. So you need RULES

Classic solution to implement this rules is to have some tables in your database like: user, roles, user_roles, role_permission, permission_option. Option table must have registered all your api endpoints and its method. Also this could be used to create the relation between user <:> web routes. Check this

You could develop your own security platform taking into consideration the previous rules or use some platforms called oauth2 platform/providers, Identity/Access Platforms, etc:

  • auth0
  • keycloack, etc

More details here: https://stackoverflow.com/a/62049409/3957754

Questions Part 3

  • it seems like OAuth2 is different from SSO, how can they work together?

As a summary, SSO just ensures that all your user could access to apps and webs with the same user/password.

Oauth2 is strictly related to authorization, but authorization is not possible with authentication, and authentication is related to user/password, so this is the relationship between oauth2 and sso

Some links

user_39577540
Related