OAuth: the desired scopes must be specified explicitly (v.22, breaking change)

Take a look at this HTTP request:

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

As you may have guessed, we'll acquire an access token. And as stated in the "scope", this token will have read-only access. But,

That's not quite true if your trusted application (i.e., client_id=my.trusted.app/first) defines the "update" scope. The returned access token will also have it.

In other words, no matter what scope you specify when requesting an access token, the resulting one will have scopes exactly as the trusted application.

This sounds like a bug. And in fact, it is.

It's fixed in 2022.

Now the scopes of the access token are only those that are explicitly specified (i.e. requested). According to the example above- you will no longer get (silently) an update access- you need to specify it as follows: "scope=DomainApi, update".

Does this change affect me?

Yes, if you have an external application that modifies data, but you are not specifying the "update" scope when requesting an access token.

What to do if this change affects me?

Just include "update" in the scope. 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&
scope=DomainApi update <----------

Remarks

1. For simplicity, an example of taking an access token via client credentials flow was used, but all this also applies in the scenario of authorization code flow. The difference is that you have specify the scope at the authorization endpoint. E.g.,

GET /id/connect/authorize HTTP/1.1
Host: demodb.my.erp.net
client_id=my.trusted.app/first&
redirect_uri={https://myapp/callback}& response_type=code id_token& scope=DomainApi update& <---------------
nonce=abc&
state=xyz

2. Even though your access tokens had "update" scope silently, this only applies if the corresponding trusted application allows it. E.g. if the trusted app also has the "update" scope.

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk