When your external service application requires an access token, you have to make a request like this:
POST /id/connect/token HTTP/1.1
Host: demodb.my.erp.net
Content-Type: application/x-www-form-urlencoded
client_id=my.trusted.app/first&
client_secret=<my_plain_app_secret>&
grant_type=client_credentials&
scope=DomainApi update
This is a completely normal request and you'll receive an access token in response. This access token will contain exactly the scopes you requested (assuming that your trusted app defined them).
OK, but let's see the following scenario- after a certain time your trusted app adds more scopes in its definition. And what does it mean if your external (service) application also needs to support it? Means it needs to be corrected and start requiring that new scope(s) in its request. That's inconvenient, isn't it?
Well, that's no longer necessary, because, starting from version 22, the scope argument is optional.
So, if your external application needs all the scopes, defined by the trusted application, you can just omit the scope argument when requesting an access token.
E.g.,
POST /id/connect/token HTTP/1.1
Host: demodb.my.erp.net
Content-Type: application/x-www-form-urlencoded
client_id=my.trusted.app/first&
client_secret=<my_plain_app_secret>&
grant_type=client_credentials
And you'll get this as a response:
{
"access_token": "<your_shiny_new_access_token>",
"expires_in": 3600,
"token_type": "Bearer",
"scope": "DomainApi openid profile update" <--- all the scopes, defined by your trusted app.
}
Remarks
1. Omitting the scope argument is our SUGGESTED way to obtain an access token for service applications.
2. The scope argument is optional only in the client credentials flow. In contrast, it's still required when using then authorization code flow.
3. The issued access token won't contain scope, not defined by the corresponding trusted application.
4. If your request contains scope, not defined by your trusted application, you'll end up with an error - HTTP 400 - invalid scope.
0 Comments