I have a scenario where I absolutely need to get OIDC request without openid scope. Can anybody help please, without openid scope always getting error "Identity related scope requests, but no openid scope".
Related
My MVC client's access token contains an "idp" claim that my simple server-to-server client's token doesn't. I don't explicitly request idp on either clients, so where is this claim coming from? I thought it was part of "openid", and since it is available by default to MVC client, you don't need to request it, but I couldn't find any documentation/specification that confirms it. By the way, I am unable to add the openid scope to my serer-to-server client, as I am getting "invalid scope" error when I do that. What I am trying to do here is to get the "idp" claim into the token for my server-to-server client as well, but not sure if that's possible. Can someone point me to the right direction?
When you do server to server communication using the client-credentials flow, there is no user involved and hence the openid scope has no purpose. As its core purpose is to ask for the subject claim (the user Id).
The idp claim is not part of any scope and is usually added by IdentityServer.
Why do you neeed the idp claim? Your API and client both trusts the shared IdentiyServer.
idp claim in Identityserver stands for external identity provider (such as Google). That's why it does not have any sense when you request a token from your local IdP with "service_credentials" flow. If you are interested in the info about the token's issuer, just use iss claim instead. If you are sure you need the idp (or any other custom) claim in each and every token, you can involve a custom ClaimsService as I explained in my previous answer.
I set up Web Api Application in Azure AD and define some scopes here, also set up SPA Application and give permission to created scopes.
When I login I requested that definitely this api scope included and I need to give permission to it. But when I request token silently with this scope I couldn't find that it has been incorporated in token.
Here request to get token with app scope
Here what token I get (without my custom scope):
Could you help me, why it's happening?
User.Read is a permission of Microsoft Graph. It recognizes the resource you want to access as Microsoft Graph.
Please remove it when you refresh your access token. Just put api://{client-id}/access_as_user openid profile offline_access as the scope.
The Microsoft Authentcation is very complex in my eyes. There are so many flows and stuff going!
So what I'm doing currently is
Get a token for a specific scope using the Authorization code flow. I'm using the following scope: https://admin.services.crm.dynamics.com//user_impersonation (as far as I know I can only request a token for a single scope/audience)
The token works fine. I can access the dynamics admin center with the bearer token I received.
What I'm trying to do now is the following:
I'm trying to access the Microsoft Graph endpoint to read information about the users AAD.
I cannot use the existing token from above, as this one only has the user_importation scope for https://admin.services.crm.dynamics.com/
I have to request another token with the scope user.read
That's where I'm stuck. How can I use the existing access_token to request an additional scope?
I can use the oauth2/v2.0/token endpoint in combination with the refresh token to request a token for another scope (user.read). This works fine, but I don't want to use the refresh token for this, but instead use the access_token. Is this even possible and makes sense?
Is this even possible and makes sense?
No, you could not use access token to get new access token with addition scope.
As you have said, you could use refresh token to request a new access token for another scope. Refresh tokens do not have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long. Although refresh tokens aren't revoked when used to acquire new access tokens, you are expected to discard the old refresh token.
POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=https://admin.services.crm.dynamics.com/user_impersonation user.read
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh // NOTE: Only required for web apps
And you could refer to this tutorial.
The scenario that you are looking for is called incremental consent. This is totally doable with MSAL. It would be great to know what platform are you developing by the way.
What you can do is to request an access token for user.read and expects MsalUiRequiredException to be thrown. In its catch, you make an interactive call with user.read as scope. With this approach, you will be implementing the incremental consent. Note that user_impersonation will still be available to use after this, and your token cache will now have both scopes.
I'd like to set up IdentityServer4 to allow "*" to be passed in as the scope during an authentication request, and then the server will figure out which scopes the client has access to.
Is there an IdentityServer4 class I can override/implement that can "resolve/modify" the scopes that are sent in?
According to OpenID Connect protocol specification, all the authorization
requests MUST contain the openid scope value. If the openid scope
value is not present, the behavior is entirely unspecified. Other
scope values MAY be present
However with Identityserver you can call the Token endpoint without scope parameter in the request and get all the scopes allowed for the client. client_credentials is exactly such a case, so you don't need any "asterisks".
If you would like to perform some "special magic", you can look into ScopeValidator as well as ICustomAuthorizeRequestValidator and ICustomTokenRequestValidator implementations. The last two are the main (and the simplest) extensibility points for any request processing.
I'm using the v1 Azure AD auth URLs (/common/oauth2/authorize) for a multi-tenant app that requires admin_consent.
I've attempted to add a new scope Directory.AccessAsUser.All. It is the first 'delegated' permission I'm requesting when all my other scopes are 'application' level permissions.
When I added that new delegated scope and prompted the admin to re-consent, the other scopes disappeared from the returned AccessToken and the responses scope parameter. Only Directory.AccessAsUser.All is present in the access_token scp field.
Is there any reason this behavior would occur? I'm positive that we are promoting for admin_consent and that an admin is the one consenting.
The scopes specified in the scp will depend on which OAUTH flow you used to obtain the token. You cannot have a single access_token with both Delegated and Application scopes.
Application scopes are applied when using the Client Credentials flow (client_credentials).
Delegated scopes are applied when using either Authorization Code or Implicit flows (authorization_code or implicit).
Update: I've written a more in-depth post about this topic that might help folks facing similar issues: Application vs Delegated Scopes.