I am trying to get the scopes that a user has consented to into the token.
I am requesting the following scopes:
I see them on the consent screen:
But when I decode the token that I receive, only the openid scope is available in the scopes.
What do I have to configure so that all scopes that the user has consented to are included in the token?
Thanks in advance
Related
I am using Forgerock as my identity provider and am looking for something in their rest api where i can provide an access token in the form of a Authorisation Bearer Token and get the corresponding JWT token to use as a Authorisation Bearer Token in a subsequent rest api call.
Can someone help me with what endpoint I can call in Forgerock to do this? I've had a look at the userinfo endpoint, that seems to return what is in the id_token in json format, but I want the actual id_token. A "token exchange".
thanks
There is no endpoint defined by specifications to obtain and ID token for an access token. Specificaitons define about token intrsopection endpoint (RFC7662) and user info endpoint (which you have already figured out).
Other than these, best option is to obtain ID Token from token response itself. For this you need to follow OpenID Connect request format, which include scope value openid. For this, you will require end use consent (most of the time) which allows authorization server to share their claims through id token.
Google Doc says that you can specify response_type for gapi?.auth.authorize
You can use it to get id_token
I am trying to request an access token for EWS with a regular #outlook.com Office 365 account. Using EWS with Basic Auth is working without problems.
I am requesting the scope
https://outlook.office365.com/EWS.AccessAsUser.All
from https://login.microsoftonline.com/common.
With an account from our organization this token is granted and access is possible. But with the #outlook.com account it givers me the error
The provided resource value for the input parameter 'scope' is not valid
Where is the difference between an organization Office 365 Account and #outlook.com account. And why are the valid scopes different?
The scope is "https://outlook.office.com/EWS.AccessAsUser.All".
Try this code: https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth
I'm trying to hit https://graph.microsoft.com/v1.0/users/{userId}/mailboxSettings endpoint with an auth token and in return receiving a 403 Error Access Denied response.
I have granted both application level and delegated permissions for MailboxSettings.Read, MailboxSettings.ReadWrite. I can verify that these permissions are enabled on the installed application via examination of my decoded auth token with the jwt.ms. Here is the exert from the decoded token:
"scp": "Directory.AccessAsUser.All Files.ReadWrite.All Group.ReadWrite.All Mail.Read Mail.ReadWrite Mail.Send MailboxSettings.Read MailboxSettings.ReadWrite Sites.ReadWrite.All"
I have also verified that the user I am requesting mailboxSettings for has been granted access via Admin Consent.
I am able to return mailboxSettings if I hit the endpoint for either the admin userId or the https://graph.microsoft.com/v1.0/users/me/mailboxSettings endpoint. Any help would be much appreciated.
Quickly I tested with Microsoft Graph Explorer and it works for me. So i would request you to test the above API call with Graph Explorer and see if you can repro the issue or not.
I believe the problem is that your token was generated using Delegated scopes. The Delegated flavor of MailboxSettings.Read and MailboxSettings.ReadWrite may only access the currently authenticated user’s mailbox.
In order to access other users, you need to use Application scopes. You can read more about how these scopes work (and how to select them) in this blog post: Application vs Delegated Scopes.
As others have stated, delegated token only works for reading the mailboxSettings of the currently authenticated user. I had enabled mailboxSettings as an Application scope, yet I was getting the same error. The culprit of the issue was that I was using the Auth code grant for the token.
After switching to Client Credentials grant, I am successfully retrieving an Auth token that contains the mailboxSettings Application level scope, and am able to get 200 responses on endpoints for all users.
I am asking a question conceptually here as I am trying to understand the relationship between scopes and user roles in an OAuth2 based system.
As I am implementing an API, I want to restrict access to specific resources by using scopes on the resources. I understand the use of access tokens to request resources, and I believe my understanding to be correct in that you specify your scope(s) when requesting the access token.
What I am not entirely sure of is how restriction of scopes would work based on specific roles that an authenticated user is in. Let's assume Bob is an admin and Sue is a regular user. We have some resources protected by an is_admin scope. What stops Sue from requesting (and receiving) is_admin scope in her access token?
I am thinking that what should happen is the following:
Bob authenticates.
Bob's roles are looked up after his authentication is complete. His "admin" role has the "is_admin" scope attached.
Bob asks for an access token with all the scopes collected from his various roles
Bob is automatically given those scopes for his access token
Is it up to my calling app to enforce only sending asking for the scope Bobs needs? Or is there something I am missing with regards to scopes?
Can someone please enlighten me with some simple examples?
In OAuth2, there are the following roles:
Resource owner - usually some person
Auth provider - the OAuth2 server
Resource server - an API that requires an access token and validates its scopes
Client application - application requesting an access token with some scopes.
To understand OAuth2, it's necessary to think about it as a protocol for access rights delegation from a Resource owner to a Client application. So the main use case is: the Client application wants to access the Resource server. In order to do that, the Client application needs an access token issued by the Auth provider and authorized by the Resource owner (which gets authenticated by the Auth provider).
In your description, the Client application is missing. Let's assume it's a frontend application for your API. It needs an access token with scopes admin-user-scope or regular-user-scope. So it redirect a user (Resource owner) to the Auth provider, requesting both scopes.
The Auth provider authenticates the user and asks him/her for a consent on granting some of the requested scopes to the Client application. The Auth provider may remove some scopes - for example the admin-user-scope for non-admins. The Auth provider may give the user a possibility to remove some scopes too.
The Client application receives an access token (or a grant) with scopes in a redirect URI. If the granted scopes differ from the requested scopes, the Auth provider sends a list of granted scopes (the scope URL parameter) along with the access token, so the Client application knows what actions it can perform with the access token.
Then the client application may access the Resource server and the Resource server makes sure that the provided access token contains required scopes. The Resource server uses the OAuth2 introspection endpoint to validate the token and to get a list of its scopes.
Is it possible to get user details (attributes belonging to the resource owner) from ForgeRock's OpenAM using an OAuth 2 access token?
I have a trusted SPA UI that is able to get an access token from OpenAM using the Resource Owner Password Credentials Grant type. However, that access token gives me no information about the resource owner. The token_info endpoint similarly gives me no information.
OpenAM seems to have endpoints for listing user attributes, but expects a JWT as means of authentication for the request.
How can I get user attributes from an access token?
There is a userinfo endpoint that will return user attributes. In OpenAM 13.0, the data returned by the endpoint is scriptable. In prior versions it is mapped to scopes.
The sample client application is helpful to understand how this works:
https://github.com/ForgeRock/openid