Using Resource Indicators in order to get downscaled Access Tokens
Several APIs require Access Tokens with the API Resource as the only audience in the aud
claim. If a Client needs to
- consume more than one API, and
- at least one of these APIs requires it's audience as the only audience in the Access Token
then, the Client can utilize the Resource Indicator mechanism in order to get Access Tokens that only contain a specific audience in the aud
claim. This is what´s called a downscaled Access Token.
The specification for this mechanism can be found in Resource Indicators for OAuth 2.0.
Example code, which demonstrates the use of this mechanism, can be found in our public GitHub repository.
How to request multiple APIs by using Resource Indicators
We give an example, with two APIs, both of which require Access Tokens with a single audience.
API-name (audience) | Scopes | |
---|---|---|
API 1 | nhn:siffer-tjeneste |
nhn:siffer-tjeneste/primtall |
API 2 | nhn:tekst-tjeneste |
nhn:tekst-tjeneste/bokstaver |
Authenticating the user and indicating resources
In the first request to the PAR endpoint, the Client must set the following values:
- In the
resource
parameters: indicate which API resources that it needs to request. The parameters must be equivalent to the audiences for each API. - In the
scope
parameter: the scopes the Client will use in order to consume the APIs - In the
scope
parameter: set theoffline_access
scope in order to get a Refresh Token in the response
Example request to the PAR endpoint:
POST /connect/par HTTP/1.1
Host: helseid-sts.nhn.no
Content-Type: application/x-www-form-urlencoded
resource=nhn:siffer-tjeneste&
resource=nhn:tekst-tjeneste&
scope=nhn:openid profile offline_access siffer-tjeneste/primtall nhn:tekst-tjeneste/bokstaver&
client_id=973f132f-47e5-4fb2-b211-43c242b7fce0&
... other parameters ...
Requesting the first Access Token
When the Client retrieves the code from the Authorization endpoint, it can specify the resource for which it wants to retrieve an Access Token. In our case, this will be resource=nhn:siffer-tjeneste
.
POST /connect/token HTTP/1.1
Host: helseid-sts.nhn.no
Content-Type: application/x-www-form-urlencoded
resource=nhn:siffer-tjeneste&
grant_type=authorization_code&
client_id=973f132f-47e5-4fb2-b211-43c242b7fce0&
... other parameters ...
The response from this request will contain an Access Token where the aud
claim contains (only) the value nhn:siffer-tjeneste
, and the scope
claim contains the value nhn:siffer-tjeneste/primtall
.
Requesting the next Access Token
The Client can now use the Refresh Token to get another Access Token with a different value in the aud
claim:
POST /connect/token HTTP/1.1
Host: helseid-sts.nhn.no
Content-Type: application/x-www-form-urlencoded
resource=nhn:tekst-tjeneste&
grant_type=refresh_token&
client_id=973f132f-47e5-4fb2-b211-43c242b7fce0&
... other parameters ...
The response from this request will now return an Access Token where the aud
claim contains (only) the value nhn:tekst-tjeneste
, and the scope
claim contains the value nhn:tekst-tjeneste/bokstaver
.
Remember that both Access Tokens can be used for authorization against the APIs as long as their expiration time holds.