OAuth OpenID Connect

OAuth and OpenID Connect
Leopold Gault
Leo’s notes

OAuth 2.0 authorization framework
It is for authorizations, not authentications.
It enables a 3rd party app (i.e. a RESTful API client) to obtain limited access to a RESTful API. This
is done either:
• on behalf of a resource owner (the idividual about whom the RESTful API will communicate
data) by orchestrating an approval interaction between the resource owner and the RESTful
API,
• or by allowing the third-party application to obtain access on its own behalf.

Different words, same meaning
OAuth’s wording Leo’s wording OpenID Connect’s wording
client API client relying party
resource owner user end-user
resource server API
authorisation server authorisation server (e.g. IDCS) Open ID Provider (an Autho Server
that can provide an ID Token (in JWT)
containing claims about the authentication of
the end user, performed by the Autho server).

Example of use-case 1
An individual having a bank account may allow a financial data aggregator app to access her
bank information (e.g. checking balance) on her behalf.
API client
E.g. a “Financial
data aggregator”
app
RESTful API
E.g. HSBC
User of the Financial data aggregator app,
having a bank account at HSBC
GET

A Linkedin user “syncs” her Linkedin account with her Twitter one: i.e. what she posts on
Linkedin will be automatically posted on Twitter too, and on her behalf.
API client
E.g. Linkedin RESTful API
E.g. Twitter
Linkedin user, having a Twitter account
POST

Alice grants Tinder access to information about her from her Facebook account.
API client
E.g. Tinder
RESTful API
E.g. Facebook
User of Tinder, having a
Facebook account
GET

Example of 3rd party apps that were granted limited access to Alice’s
Facebook account (i.e. those apps were registered in Facebook’s Autho
Server)
Screenshot from Tinder,
redirecting you to Facebook in
order to get your consent.
Alice

Stakeholders
API client
Wants to access some
data about the
resource owner on the
API
RESTful API
Holds data about
the user
Resource owner: owns data on the API
Grants authorization

Stakeholders
API client
It was 1st registered in
the Autho Server
RESTful API
Accepts Access
Tokens (for the
HTTP Authentication
header)
Resource owner: owns data on the API
Authorization Server
Gets Authorization consent
from the resource owner, and
send this Autho Grant back to
the API client.
It can then exchange this
Autho Grant against an
Access Token.

Registration of the API Client in the Autho Server
As a pre-requisite, the 3rd party app (API client) has first to be registered in the Authorization
Server (before being able to request authorizations on behalf of a resource owner).

Registration of the API Client in the Autho Server
Specification of scopes

OAuth Protocol Flow
Using the API clientID + API
client secret, which are
configured when
registering the API client in
the Autho Server
The Access Token
denotes an
authorization rather
than an
authentication; but
HTTP only supports
an Authentication
header. So we pass
the access token in
the authentication
header.
Autho Code,
implicit, etc.

Tinder
data about the user
on the API
Tinder-Facebook Example
Facebook
Holds data about
Alice
Facebook’s
Gets Alice's consent to allow
Tinder to access her Facebook
data.
Alice: the resource owner (owns data on
Facebook)
GET request to /authorize
“Please provide Tinder an
Authorization Grant.”
Request params:
• (API)-client ID: Tinder’s
• Scope: pictures and likes
• Local state: ??
• Redirection URI:(url to
which the Auth Grant is
returned): xxx (in the case
of OAuth public clients, it will
be localhost –and the Autho
Grant will be of implicit type)
/authorize

Tinder
data about the user
on the API
Facebook
Facebook)
The Authorization Server
authenticates Alice
Facebook’s
It is also the IdP : only the
Autho Server authenticates the
resource owner; the API does
not.
Don’t be fooled by the Facebook logo : this is not the
Facebook API, this page is from the Autho Server. The API
doesn’t perform any authentication : it answers to requests
exactly the same way to all requests having the same
request params. It does not control for who was the resource
owner who granted the authorization (that was used to
obtain the access token) –however the API could do so if it
wanted. However, the API probably controls the scope of the
access token, and its response may vary depending on the
scope included in the Access Token.
/loggin

About the Authentication of the resource owner by the Autho
Server
It is thus clear that it is the Autho Server that authenticates the resource owner, and gets the her consent. What is interesting is that they
imply that the resource owner is authenticated by the Autho Server, by sending her credentials to the latter. I suppose the Autho Server
then uses those credentials against the resource server, to test their validity.

Tinder
data about the user
on the API
Facebook
Facebook)
authenticates Alice
Facebook’s
It is also the IdP : only the Autho
Server authenticates the resource
owner; the API does not.
If the identity of the user is federated (federation between IDCS and an external
IdP), then IDCS will get a SAML assertion from that external IdP, instead of the
user’s credentials. This is what we saw in the AMCe Browser SSO thingy.
/loggin

AMCe : Browser based SSO using IDCS as the IdP
Federated IdP
/authorize
/token
1) Open web-browser to /authorize
GET
1.1) The web-browser executes auto submit
form (JS)
POST auto-submit form
1.3) The user submits his credentials
POST credentials
IDCS sign-in Html page
1.2) The user clicks on SSO link
GET login page
IdP sign-in html page
Auto-submit form to IDCS
containing SAML response
1.4.1) The web-browser executes the auto-submit form
(JS)
POST
/sso
302 SAML response
/loggin
/consent
GET (using previously responded Location header)
303
303 with redirect url and Auth code
2) Post auth code
POST Auth code
1.4.2) The web-browser redirects to the url contained
in the Location header of the previous response
IDCS
Generate auth code
Auto-submit form
(JS) to IDCS
/signin
Generate SAML Response
OAuth access token
Before providing an auth-code, the OAuth Authorization
Server (IDCS) must:
1. Authenticate the resource owner, who owns data in the
mobile backend. Here, as we are using an external IdP,
we will get from the later a SAML assertion to
authenticate the resource owner.
2. Make sure that the resource owner consents to grant the
mobile-backend client (i.e. the mobile app) access to the
scope of data (this is already done : contained in the
parameters provided in the GET request against the
/authorize endpoint)
All of these endpoints (green and burgundy) are for OAuth. O
/authorize and /token are mentioned in the OAuth RFC, but th
green ones are part of the implementation of an Autho Serve
too.
Here I don’t think that using a redirection is the standard way. I
think that the resource owner is supposed to explicitly click on “I
consent to grant my authorization”. But in this precise case, the
API client (mobile front end) is tightly bound to the API (the
mobile backend); so we can go ahead and skip that explicit
consent grant by the resource owner.

Tinder
data about the user
on the API
Facebook)
Authorization
Server
Gets Alice's consent to
allow Tinder to access her
Facebook data.
asks for Alice’s consent
Authorization granted
Don’t be fooled by this Facebook logo. This page has
been sent by the Autho Server, not the Resource Server
(Facebook)
Facebook
/consent

Tinder
data about the user
on the API
Facebook
Holds data about
the user
Facebook)
Authorization
Server
Once Alice’s consent it
obtained, the Autho Server
sends an Autho Grant
grant

Tinder
data about the user
on the API
Facebook
Holds data about
the user
Facebook)
Authorization
Server
Exchanges an
Authorization Grant
against an OAuth Token
grant
+ Authentication
of Tinder
This is done either by using:
• The API Client ID + API
Client Secret. Those were
set up when registering
Tinder as an OAuth
Confidential client in the
Authorization server.
• The redirect url (to which
is returned the implicit
grant), when setting up
tinder as an OAuth Public
client in the Autho server
/token

API client authentication to the Autho Server
This can be done either:
• using client ID + client secret , in the context of a confidential client-type
• or a well configured client redirect url, in the context of a public client-type.
• Indeed, if I specify it a localhost/myAPIclient, then only the API client residing on the same device as the user-agent
can get the Autho Code.
• Usually, public client-types use the Autho Grant type "implicit".
• It is mandatory for public client types to have their redirect URL registered, as it seems to be the only way to
"authenticate" the API client.

Authorization tab
Step 2: POST against /token
https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/op-
oauth2-v1-token-post.html

Body tab

Headers tab

Tinder
data about the user
on the API
Facebook
Holds data about
the user
Facebook)
Authorization
Server
“Please send me her
pictures. Here is my
authorization token.”

Tinder
data about the user
on the API
Facebook
Holds data about
the user
Facebook)
Authorization
Server
“Please send me her
pictures. Here is my
authorization token.”
How does the API know the definition of the access scope (eg likes,
pictures, friends)? -The implementation of the API decides the
mapping of data to a specific scope. But how is the scope provided
to the API? I don’t think it’s in the request parameters.
And how does the API know that this Access Token is to be
associated to this resource owner, and not another one? Does the
Access Token contain the user-ID (as used when authenticating
her), or does it rely on something else (eg Open ID Connect –
although OpenID Connect is meant for the API client, not the API)?
The Access Token is opaque to the API Client. It probably
also is to the API. But the API Client can use OpenID
Connect to retrieve the username of the resource owner,
and use it in the request params (for requests against
the API).
Okay, but how does the API know that this Access
Token is valid, and for the proper scope?
I think that the API has to send the Access Token to the
Autho Server, which responds with a green lights for
the scopes that were agreed on when providing to the
API client the Autho Grant.
So I suppose the API sends this Access Token to the
Autho Server, which responds “username: Alice;
scope:likes”. The API implementation specifies which
data is covered by the scope “likes”, and considers the
API request as authenticated by the user Alice.
Indeed, the API can send the Access Token to the
/introspection endpoint of the Autho Server, so as to
get in cleartext the scope, expiration status of the
token, who authorized the token and which client it was
issued to. See RFC 7662
But I think that the Access Token in not opaque to the
API : the Access Token is signed by the Autho Server,
and the API needs to verify the signature, and thus can
read the de-crypted content. It can read in plain text the
expiration date and the scope. But for any further info,
it will have to call the /introspect endpoint.
But let’s be clear: the API doesn’t act like anyone was
authenticated : as long as the Access Token is valid, it
give the data about any resource owner that is specified
in the request parameters. However it will control for the
scope; and the scope will only be about certain data of a
specific resource owner.

An Access Token, delivered by Auth0 (an Autho Server implementation)
{
"iss": "https://AuthoServer/",
"sub": "auth0|123456",
"aud": [ "my-api-identifier", "https://AuthoServer/userinfo" ],
"azp": "YOUR_API_CLIENT_ID",
"exp": 1489179954,
"iat": 1489143954,
"scope": "openid profile email address phone read:appointments"
}
“Note that the token does not contain any information about the user (resource owner) itself besides their ID (sub claim). It only contains authorization information about which
actions the application is allowed to perform at the API (scope claim). This is what makes it useful for securing an API, but not for authenticating a user.
In many cases, you might find it useful to retrieve additional user information at the API, so the Access Token is also valid for calling the /userinfo API, which returns the user's
profile information. The intended audience (indicated by the aud claim) for this token is both your custom API as specified by its identifier (such as https://my-api-identifier) and
the /userinfo endpoint (such as https://YOUR_DOMAIN/userinfo).”
https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis#keep-reading
This is probably the same thing as the
/introspect endpoint. Auth0 may have decided
to give it another name.

Authorization Grants
There are 4 types:
• Authentication code
• Implicit: the api-client is issued an access token directly.
• Resource owner (user) password credentials : they are used directly by the API client to
obtain an access token. The credentials are not stored by the API client : the latter can use a
refresh token.
• Client (API client) credentials –the client ID and secret ?
A credential representing the user’s authorization

Access Token
• It’s a string denoting a specific scope, lifetime, and other access attributes.
• The resource server (i.e. the RESTful API) will accept any request with a valid Access Token.
This means that the API client doesn’t have to authenticate towards the API; presenting the
Access Token (in the HTTP Authorization Header) is enough.

Authorization Code Flow (preferred way for obtaining and Authorization Grant)
(API client)
(user)
(user’s web
browser)

Refresh token
Another important thing to note is that an Access Token may be refreshed. So an API client may ask for an Access Token
only once in a lifetime, and then only ask for refreshes. This is especially important in the context of the "resource owner
credentials" Autho Grant type. Indeed, in such situation, the API client does not have to store the resource owner (user)'s
credentials; as it will request the Autho Token only once, and then get refreshes.

OpenID Connect
OpenID Connect is only used by the API client, in order to get information about the
authentication of the resource owner that was performed by the Autho Server. The API client
requests such information in the scope param when calling /Authorize endpoint. The
authentication information is returned in the form of a JWT token (aka ID Token).

OpenID Connect
In the OAuth spec, I think they hint at OpenID Connect in the following paragraph (about Autho
Token) - the "beyond the scope of this spec" part:
An ID Token is obtained the same way as an Access Token: it is exchanged against an
authorization code, at the /token endpoint. The API client can then find in that ID Token the
subject identifier (i.e. the username of the resource owner).

OpenID Connect
My understanding is that OpenID Connect is a way, for the API client, to get information
about the authentication of the resource owner, that was performed by the autho server:
• the API client knows that the resource owner has been properly authenticated by the Autho
Server
• so the API client can rely on the Autho Code as a proof that the resource owner has been
authenticated
• But, to the API-client, both the Autho Code and Autho are opaque strings. So the API-client
cannot get information about the authentication of the resource owner: no username, no
expiration date, no Issuer information. ID Tokens solve that: they contain information about
the authentication performed by the Autho Server, that can be used as authentication
information for the API client.
• That's what allows you to loggin with your Facebook account in Tinder; instead of just
allowing Tinder to access your Facebook pictures, but still having to create a Tinder account.
The ID Token will provide Tinder info such as your name (in Facebook), profile picture, etc.

Example of an ID Token
{
"iss": "http://AuthoServer/",
"sub": "auth0|123456",
"aud": "YOUR_API_CLIENT_ID",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
Info about the
resource owner
This token is meant to authenticate the user to the application. The audience (the aud claim) of the token is set
to the API-client’s identifier, which means that only this specific API-client should consume this token.

Access Token VS ID Token
{
"iss": "http:// AuthoServer/",
"sub": "auth0|123456",
"aud": "YOUR_API_CLIENT_ID",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
{
"iss": "https://AuthoServer/",
"sub": "auth0|123456",
"aud": [ "my-api-identifier", "https://AuthoServer/userinfo" ],
"azp": "YOUR_API_CLIENT_ID",
"exp": 1489179954,
"iat": 1489143954,
"scope": "openid profile email address phone read:appointments"
}
Access Token ID Token

To read
https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis
https://www.baeldung.com/java-ee-oauth2-implementation

Using OAuth and OpenID Connect only for authentication (not
authorization consent)
When the API-client is the frond-end of the API (backend) it seems to be common to use Oauth/OpenIDConnect only as a
way to authenticate the user, and skip the “do you consent to allow the API client to access your data on the API?” part. This
allows the API not to implement any authentication mechanism, and delegate it all to the OpenID Provider (Autho Server).
This is what we’ve seen in AMCe : the API-client (mobile app) is just the front-end of the API (mobile-backend). The consent
is thus automatically granted with an HTTP 303.
This is also true for cloud services in IDCS: for instance in OAC,
• <the webconsole of the OAC instance> is <the API-client>,
• and <OAC instance’s API> is <the resource server (API)>.

This is the url of the initiator, who called the callback OAC endpoint. I didn’t call this /consent url; it was called
automatically. Once called, the /consent redirected to a callback endpoint on this OAC instance, with the ID Token (
because we’re using the Implicit autho grant type, an access token should be issued directly; I suppose it is the same for
an ID Token).

OAuth OpenID Connect

More Related Content

What's hot (19)

Similar to OAuth OpenID Connect (20)

More from Léopold Gault (7)

Recently uploaded (20)

OAuth OpenID Connect