Everything about Authentication and Authorisation: SSO, SAML, OpenID, OAuth, and Cognito

Photo by Dina Nasyrova on Unsplash

Not long ago, I was tasked to work on a project about configuring the SSO with AWS Cognito. The project itself went fine, but before I dived into the project, I spent quite some time to figure out the concept of authentication & authorisation, the typical workflows, as well as the industry standards.

In short:

• Authentication: Who the user is
• Authorisation: What the user can access (authentication is normally the first step of authorisation)

Single sign-on

Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID and password to any of the group of services.

The key difference vs. direct authentication is that : in SSO, service provider uses a 3rd party, aka. identity provider to check user identity, but it does not actually store user identity, while in DA, an user’s access credentials are stored in with the service provider.

Workflow:

0. Application configs with the authorisation server (establish trust between then)

1. User logs in the 1st time, the application redirects the user to the authorisation server (e.g. Google).
2. The authorisation server asks user to log in.
3. (authentication) If successful, the authorisation server redirects the user to the application, returning a token (a SAML token if using SAML) that contains identity information for the user.
4. (Optional — authorisation)If the application wants to get some data from the authorisation server about the user, it needs to ask permission in the request sent in step 1, and normally the authorisation server will ask the user (e.g. Google: do you want to the “XXX application” to use your contacts ?”), explicitly upon user signing in, and if granted, will sent this authorisation information along with other information in step 3 above.

SSO vs. Federated identity management

Similar to SSO, FIM enables users to use a single credential to access resources of different applications.

Note the difference between SSO and FIM is that for SSO, it is one credential across different systems under one organisation, for federated identity system, it is one credential to a different applications from various organisations.

SSO Protocols

SAML, OAuth, and OpenID are all protocols.

OAuth 2.0 is mainly for authorization process to access protected resource, while OpenID Connect and SAML are both for authentication. So OAuth 2.0 can be used with either OpenID Connect or SAML, and is often used with OpenID.

SAML

SAML (Security Assertion Mark-up Language) is an umbrella term that covers federation, identity management and single sign-on (SSO). It allows that identity providers (IdP) to pass authorisation credentials to service providers (SP).

A SAML Assertion is the XML document that the identity provider sends to the service provider about the user.

• Authentication assertions: proves identification of the user
• Attribution assertion: provide information about the user
• Authorization decision assertion says if the user is authorized to use the service or if the identify provider denied their request due to a password failure or lack of rights to the service.

OAuth 2.0

OAuth 2.0 came after SAML. As an example, Facebook and Google are 2 OAuth providers popular for social logins.

OAuth is a service that is complementary to and distinct from OpenID. OAuth is unrelated to OATH, which is a reference architecture for authentication, not a standard for authorization. However, OAuth is directly related to OpenID Connect (OIDC), since OIDC is an authentication layer built on top of OAuth 2.0.

In general, OAuth authentication follows a six step pattern:

1. An application requests authorisation on a user’s behalf.
2. The application obtains a Grant Token.
3. The client requests an access token by using the Grant Token.
4. The authorisation server validates the Grant Token and issues an Access Token and a Refresh Token.
5. The client requests the protected resource, authenticating using the Access Token.
6. The resource server verifies the Access Token with the authorisation server (without bothering client) and serves the request(This part also authenticate the client, as authentication is the first step for authorisation).

OpenID Connect

OpenID Connect is built on the OAuth 2.0 and uses an additional JSON Web Token (JWT). It is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps.

The protocol uses RESTful API communication to transmit JSON web tokens between the identity provider and service provider, for data containing e.g. user’s name, email address, etc.

SAML vs. OAuth vs.OpenID

OAuth is better on mobile and uses JSON. SAML, on the other hand, provides more control to enterprises using the XML markups.

But the main hassle is that in the redirect from authorisation server to the application, which normally uses a POST form, the user has to click a button to submit or it has to be automated using JavaScript. On a mobile application, this would not work, as the application does not have access to the POST data.

For OAuth, after receiving a request with an accompanying Access Token (step 6. above), the service verifies the validity of the token directly with the authorisation server. So there is no HTTP Post, but just an additional round trip from service to authorisation server to authenticate the client (In SAML, this authentication information contains in the SAML token).

We can now skip the awkward HTTP POST dance, but only at the price of an additional round trip to the Authorisation Server. This is caused by the different underlying trust models and their embodiments, the tokens. SAML Assertions or “SAML tokens” contain the user identification information , while with OAuth the Resource Server needs to make additional round trip in order to authenticate the Client with the Authorisation Server.

What if you can’t choose between SAML and OAuth? Good news, one can always use both. In this scenario, the SAML Assertion can be used as an OAuth Bearer Token to access the protected resource. In addition, if the lack of authorisation is the only thing holding back on your OAuth implementation, be sure to check out OpenID and OpenID Connect, open standards that builds upon OAuth in order to provide just that.

But both can be used for SSO, especially for web applications.

For OpenID, comparing to SAML, it is often used with OAuth, and using JWT instead of XML SAML format to exchange information.

Cognito

Amazon Cognito provides authentication, authorization, and user management for web and mobile apps. Users can sign in directly with a user name and password, or through a third party such as Facebook, Amazon, Google or Apple (SSO)

The two main components of Amazon Cognito are user pools and identity pools.

User pools:

User pools are user directories that provide sign-up and sign-in options for your app users.

With a user pool, your users can sign in to your web or mobile app through Amazon Cognito, or federate through a third-party identity provider (IdP).

Identity pools

Identity pools enable you to grant your users access to other AWS services. Identity pools support anonymous guest users, as well as the following identity providers that you can use to authenticate users for identity pools:

• Amazon Cognito user pools
• Social sign-in with Facebook, Google, Login with Amazon, and Sign in with Apple
• OpenID Connect (OIDC) providers
• SAML identity providers
• Developer authenticated identities

To save user profile information, your identity pool needs to be integrated with a user pool.

The flow works as:

1. User signs in the app through a user pool and receives user pool tokens after authentication to the app.
2. App exchanges the user pool tokens for AWS credentials through an identity pool.
3. User can then use AWS credentials to access other AWS services such as Amazon S3 or DynamoDB.

Pros:

• Fully configurable
• Easy to connect with your application via provided AWS Amplify module
• UI forms for logging in, registration, password recovery, password change, federated authentication, MFA, etc.
• All user data will be stored in cloud AWS Cognito service
• Confirmation emails will be automatically sent.
• Integration with Social identity providers

That’s so much of it!

Happy Reading!