SSO, OIDC, OAuth2, Okta: what do they mean to you as a developer?

A beginner guide to authentication and authorization

Yat Man, Wong
7 min readDec 2, 2022

Like the http protocol were designed to transfer information between networked devices, SSO, OIDC, OAuth2 are all protocols designed to grant user access permission to resource between services. They are all related because they are extended concept of one another, but they solve different aspect of this user permission problem.

Authentication & Authorization Components

Authentication vs Authorization

For users to use a website/service, they need to be both authenticated and authorized to do anything. OAuth2 were designed to solve authorization problem while OIDC were designed to solve authentication problem.

  • Authentication is the process of verifying are you really who you claim you are. This can usually done by having the system check your username and password.
  • Authorization is the process of verifying that you have permission to do whatever you are doing. You might be successfully authenticate as yourself on Facebook, but unlike a Facebook admin, you have no permission to remove another user from Facebook.

Open Authorization 2.0 (OAuth2)

OAuth2 is intended to solve delegated authorization problem. You certainly have seen something like this:

For example, a user want to integrate his StackOverflow account with his Github account.

The problem is, without user handing over his Github password to StackOverflow, how can StackOverflow access some information on Github on behalf of the user?

This calls for the Authorization Code Flow

* Why we need authorization code flow?

In short, for security concern. There is indeed another flow that return the access token directly after user authentication. It is call the Implicit flow.

The URL of this redirect ends up in the browser history. So we don’t want a long lived, directly usable access token here. The short lived authorization code is less dangerous in the history.

Meaning it is access token is accessible with JavaScript, making it vulnerable to attacks like Cross-Site Request Forgery (CSRF).
In the auth code flow, the code is useless to hackers without a secret key.

Further reading:

There are variations of OAuth2 with different security measure. Proof Key for Code Exchange (PKCE), and Authorization Code Flow are improvement from the basic Implicit Code Flow.

Scope

Scope is what we allow StackOverflow(OAuth Client) to do. It specify how much authorization we are granting it.

For example, StackOverflow only has access to read my Email addresses. It cannot access my repos or commit history.

Access Token and Refresh Token

The access token you get back at the end of this flow is the token you pass to your API.

In my application, without this token, the call couldn’t even get pass Azure API Management (APIM) and wouldn’t reach my backend.

Access token also has a life time before it expires. This is the beauty of token-based process compare to session-based process. When the client is done with the authorization server, there is no additional work for the client to notify the server or for the server to clean up this session in their database. The access token will automatically expire.

There is also the refresh token which get you a new access token. When the refresh token expire, you will need to login again to receive a new pair of refresh and access token.

Below is the default lifetime from Okta. Ignore ID token for now because it is from OIDC not OAuth2.

Where does Okta come into the picture?

Okta is a type of Authorization Server. Do you think services like Github and millions of other sites would duplicate the effort to build the redirect, token verification, token refresh logic? They use enterprise solutions like Okta internally for the implementation. Okta provides SDK for these services to integrate.

It is best to have Okta describe what they do.

https://developer.okta.com/docs/concepts/auth-servers/#default-custom-authorization-server

OpenID Connect (OIDC)

Recall that OAuth2 was build for authorization. Github (Authorization server) knows who I am but StackOverflow (OAuth client) does not.

Because of OAuth2’s success, many services integrated it and were doing their own things to handle user authentication. This calls for an extension on top of OAuth2 to standardize the authentication process.

Now we can understand the explanation from the Okta site. OIDC is build on top of OAuth2. Using the same flow with the authorization server and additionally pass back an ID token to let the client identify the user.

The result is now you can login with different services because StackOverflow is able to authenticate you without knowing your Github password.

This is the different in the flow

If you want to get technical, these are the additional changes from the Okta site.

What is Inside JSON Web Token (JWT)?

One noticeable change is your token from before is now converted to JWT format. JWT is nothing complicated. It is just a industry standard to encode and decode the token stored in the token.

For example you might have a Bearer token


Authorization: Bearer {some hex string...}

If you paste it in jwt.io and decode it, you can see the json stored in the payload section. There is the scope, expire time, sub field is user id, and the issuer which is okta.


{
"iss": "https://jllpoc.oktapreview.com/oauth2/default",
"exp": 1672519869,
"uid": "00upe8f543n5iq0h7",
"scp": [
"openid",
"offline_access",
"profile",
"email"
],
"auth_time": 1672516249,
"sub": "YatMan.Wong@am.xyz.com",
"consumerclaim": "oktaauthserver=apim;..."
}

Now what does Okta do?

Again Okta is providing the support to handle ID token. Okta now becomes the identity provider. In order for this to work, the user must have at some point registered with Okta. Okta’s role will become clear when we get to SSO.

Sample Config

As a bonus, if you have implemented an OIDC flow in your application, you must have some sort of configuration file where you specify the scope and redirect_uri.
For example this is the config I have when I did my Android app.

{
"client_id":"0oaztjwy433EGqDpLe0h7",
"redirect_uri":"com.xyz.yourapp.dev:/callback",
"end_session_redirect_uri":"com.xyz.yourapp.dev:/signoutCallback",
"scopes": [
"openid",
"profile",
"offline_access"
],
"discovery_uri":"https://applogin-uat.xyz.com/oauth2/default"
}

More on the Okta Android SDK on the configuration
https://github.com/okta/okta-oidc-android#Using-JSON-configuration-file

I strongly recommend spending an hour watching this explanation from Okta.

Single-Sign-On (SSO)

OK, we talked about authentication and authorization, what’s more? Now we want a bulk solution to not repeat this login process on a group of similar sites.

When I started working with my current company, every work websites I visit direct me to this Okta login page. All. The. Work. Websites! Slack, Confluence, Azure, Hotmail, Splunk, etc…

But I only need to login to one of them. Somehow the system knows it is me again and automatically authenticate and authorize me for the others.

This has been bothering me a lot. Why is Okta everywhere? When I build my Android app I have to set up Okta (now I know specifically I was setting up the OIDC flow), why when I login to my company websites, it is also Okta?

Recall our first graph, SSO can be done using either SAML or OIDC. Lets take a look at the last flow:

Okta track my session. This is the reason why I only need to login once, and for the next couple hours I don’t need to login to other company websites. It is the same reason you only need one account to access Gmail, Youtube, Calendar, and all other Google services.

I would recommend this quick explanation on SSO flow

What is Okta?

So, to clear this confusion for myself. Okta is always the authorization server.

Okta is a commercial identity provider specified by my company. So when I am using the Okta integrated sites, Okta is tracking my session and providing my clientId and access token for these third party websites.

When I am developing my own app, I am now one of these third party websites. I need to redirect my user to enter their passwords to Okta. The Okta library I integrated in my app is to help me get the access token & refresh token from Okta.

--

--

Yat Man, Wong

Android developer, problem solver, real man in training