I got the workaround to work to add claims to the token using a custom REST API, however I realized this is the Id token and not the Access token. I need the custom claims to be the Access token to use for authorization in the service.
I haven't inspected the Access token yet but are these claims also inserted into the Access token?
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw
Yes, custom claims come back when requesting access tokens. The only difference in the list of claims is the scp claim. The scp claim is only returned on access tokens.
Unfortunately, the Claims in ID and access tokens documentation doesn't discuss this.
You can quickly verify this via the Run Now feature in the Azure Portal. See this SO answer.
Sample access token w/ a custom claim
I am using custom claims in my Azure Active Directory B2C tenant where I registered two applications (UI and API). The UI passes the access_token to the API and I am able to retrieve the custom claims there. I guess this should be also true for custom claims using a custom REST API.
If not, It must be possible to setup:
... The return claims can be stored in the user's Azure AD account,
evaluated in the next Orchestration Steps, or included in the access
token
If your question is "Can I get the user's access token from the federating IdP such as Azure AD, facebook etc"? The answer currently is no. You can vote for this feature here.
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15334347-return-social-idp-s-native-access-tokens-back-to-t
Related
What are ways to include custom claims (user subscriptions or roles list as example) in a token before issuing it in Azure AD B2C, provided that claims are stored somewhere on own server (not available in B2C)?
Goal to have claims in the token to avoid additional round trip to the storage on every request.
Investigation on the topic brought me to following ways:
Add custom attribute via Graph API, configure to include in JWT. Attribute values should be kept in sync with our datastorage.
Custom Sign-In Policy like in this article https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom but if I got it right, additional Step 6 is a user journey to publicly available API in non restricted way (request not secured by secret, might be used to get user claims by presented UserId)?
IdentityServer4 Federation gateway http://docs.identityserver.io/en/release/topics/federation_gateway.html that will allow to add any claims before issuing.
The first two mechanisms you outlined are the most common and recommended ways to include custom claims in an Azure AD B2C issued token:
Add a custom attribute and include it in the JWT. You can enable the custom attribute via the B2C UI or via the Graph API. You'd need to build your own mechanism to keep the value of this attribute in B2C in sync with your external source via the Graph API.
You can use a custom policy to add a step in your authentication flow to call a Rest API to obtain the claim and include it in the token. This call to the Rest API will be performed by the Azure AD B2C service and NOT the user's browser, so it'll be a service-to-service call (versus a client-to-service call), keeping any secrets you use for authentication with your Rest API safe (such as a Azure function code).
Background
I have two applications registered in azure, one is a web-based client and the other is a web-based service. The setup is similar to the example found here: https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi
The user logs in to the client via azure b2c, and then the client queries against the service, authenticated via azure b2c, to obtain its data.
The Problem
The service is not receiving the expected claims in the bearer token.
Specifics
Azure B2C says that the claims you select for a given policy will be included in "a token", which I assumed would be the bearer token. Below is a screencapture of some of the claims I have selected.
However, on the service when I extract the claims from the bearer token, I get none of the promised claims. Instead, I get the claims shown below.
I am using UseOAuthBearerAuthentication identical to the example provided by microsoft on github (linked above).
Am I missing something?
How do I get the claims that b2c promises?
Application Claims are included in the id_token, not the access_token (aka bearer token).
This means that the Select application claims will allow your client application (native app or web app) to access these custom claims.
If you want to access custom claims from your back-end service, you'll need to call the Azure AD Graph using the client credentials flow and call the user endpoint like so:
https://graph.windows.net/<yourtenant.onmicrosoft.com>/users/<userId>
And retrieve the property with the following format:
extension_<b2c-extensions-app_appId>_<customAttributeName>
For example:
extension_e5bf5a2db0c9415cb62661a70d8f0a68_MyCustomAttribute
You can obtain the id of your B2C tenant's b2c-extensions-app via the Graph as well:
https://graph.windows.net/<yourtenant.onmicrosoft.com>/applications?$filter=displayName eq 'b2c-extensions-app'
See this post for more info:
Moving Azure AD B2C custom user attributes across new environments
I am trying to gather metrics info of azure resources. For that i need an access token to authorize. But to get an access token i have to give client id, client secret, subscription id, tenant id.I was wondering if i could get this access token without giving so many details except username and password of my azure account.
Basically you need the parameters. Azure's APIs are protected by Azure AD so you have to authenticate against it first. If you want to make calls as the user, you still need to authenticate with one of the few ways available. The password grant (as shown in #4c74356b41 answer) is one option, though it is not really recommended. The reason is that if the user's password has expired or has MFA enabled, it won't work.
What you usually do is request the user to login via Azure AD sign-in page (via redirect or web view), and then exchange the resulting authorization code for an access token and refresh token. Then you can make calls against the APIs as the user.
Another option is to register your app in Azure AD and grant its service principal some roles in your Azure subscriptions/resource groups/resources. Then it can authenticate with client credentials (using only its client id and secret + your Azure AD tenant id).
it is possible, but it is considered not safe. And you would still need a lot of parameters:
Name Description
grant_type The OAuth 2 grant type: password
resource The app to consume the token, such as Microsoft Graph, Azure AD Graph or your own Restful service
client_id The Client Id of a registered application in Azure AD
username The user account in Azure AD
password The password of the user account
scope optional, such as openid to get Id Token
Reference:
https://blogs.msdn.microsoft.com/wushuai/2016/09/25/resource-owner-password-credentials-grant-in-azure-ad-oauth/
ps. Don't mind Walter, he is wrong like 50% of the time in his answers.
It really depends on your need and if you want this fully automated or not.
If you want to have a token for a ServicePrincipal, the answer of 4c74356b41 is a great way to do it.
However if you would want to obtain a bearer token for a user (you or another AAD user) that is already authenticated in a PowerShell session, you could do this very easily if you use this piece of code that I wrote.
https://gallery.technet.microsoft.com/scriptcenter/Easily-obtain-AccessToken-3ba6e593
Basically what it does, it fetch the current token from the token cache and return it to you. This way you don't have to deal with clientId, cliendSecret or certificate. I use this all the time when I need to call the Azure REST API on a Just In Time fashion.
I have a question about the tokens regarding Azure AD and multi-factor authentication (MFA).
So I have managed to look into what happens with tokens when they are sent for a user with and without MFA enabled.
What I observed is that in the payload of the token there is an extra claim in the: "amr": [] tag. By default there is a 'pwd' in that object, but with MFA there is also a claim called 'mfa'.
So now I know that somehow the token gets modified depending on the enabled options.
Is there some other claim or mechanism to obtain a specific ID for the device that the token was issued to. A device ID that potentially relates to its regustration through "Workplace Join" in Azure AD or through the Microsoft Authenticator App?
Is there a separate token being sent related to the Application Pass that is continuously talked about in the forums and documentation?
--------------------------Update---------------------------------
Ok so reading the application password, it's basically used as another form of authenticating the multi-factor authentication. And I guess it gets stored both on Azure AD and also on the phone somewhere inside the Authentication app.
So another question, is it possible to access this password from code?
There is no such claim about the device information in the id_token issued by Azure AD. You can refer all the claims in id_token from links below:
Azure AD token reference
Azure Active Directory v2.0 tokens reference
is it possible to access this password someone from code?
As far as I know, there is no such API like Azure Graph REST we can retrieve the password. And if you any suggestion about MFA, you can submit them from link here.
I have an application that authenticates users agains Azure AD using OAuth and I want to provide the ability to setup certain information associated to each user by his admin in Azure AD, so I can read it as part of the authentication process. I would also like to be able to use the claims functionality provided by Azure ActiveDirectory so the admin can define custom mappings between user attributes in his AD and what I am going to read, as explained here.
Apparently those claims can only be read from a SAML token that would be the result of a SAML authentication, but since I am already authenticating using OAuth I would like to avoid having to do that. My question therefore is: can those SAML tokens or the information contained in them be obtained somehow either as part of the OAuth authentication process or afterwards?
When you say "provided by ActiveDirectory" you mean Azure AD not on-premises AD?
There is no way currently to add claims to the token in Azure AD. They are "canned".
That link you refer to is for SaaS application in Azure.
The way to get information out of Azure AD is via the Graph API.