Scopes represent collections of user profile information. For example, the address scope contains information such as a user’s street address, his or her city and state, his or her zip code, etc. Likewise, the profile scope contains such things as the user’s first and last name, and the user’s gender and birthdate, and so on. Scopes enable you to automatically collect this information following a successful authentication, and make all that data accessible from the userinfo endpoint.
Oh, and scopes are easy to use, too. For example, on the OpenID Connect Playground, you can specify the scopes to be returned by selecting those scopes from a dropdown list:
That’s great … in theory. But there is a potential problem here. Suppose you go to the OpenID Connect Playground and add the address scope to your authorization request. You log on, then click the Call /Userinfo button to return data from the userinfo endpoint. And here’s what you get back:
That response isn’t exactly overflowing with address information.
But don’t panic: Identity Cloud scopes work just fine. It’s just that they also work a little differently than people might expect them to. What do we mean by that? Well, if you walk into a bank, you can ask to withdrawn a million dollars. But just because you asked to withdraw a million dollars doesn’t mean that you’ll automatically get a million dollars. Instead, you’ll only get the money you’re entitled to get. If you have a million dollars in your account you can withdraw a million dollars. If you don’t have a million dollars in your account then you can’t withdraw a million dollars.
Scopes work the same way (sort of). You can request any scopes that you want; however, that doesn’t mean that you’ll receive those scopes. Instead, you can only get back the scopes specified in the allowedScopes property of your token policy. In this case, our token policy looks like this:
"allowedScopes": [ "openid", "email" ],
As you can see, the only scopes listed in the allowedScopes property are openid (which is required for all authorization requests) and email. That means that we can get back the email scope. But we can’t get back the address scope.
Well, not unless we add address to the set of allowed scopes:
"allowedScopes": [ "openid", "email", "address" ],
Now that address is in our set of allowed scopes, we can request the address scope and get back address information from the userinfo endpoint. You know, like this:
Updated 4 months ago