Is there a way to request specific JWT Claims to show up in the "X-Endpoint-API-UserInfo" header in a Google Cloud Endpoints oauth scenario?
As background, I have successfully had Google Cloud Endpoints validate my JWT token from Azure Oauth, however the data passed through in the header by Google Cloud Endpoints is limited and does not adequately contain enough information from the original Claims.
The claims provided by Azure can be found here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code.
For example
{
"aud": "2d4d11a2-f814-46a7-890a-274a72a7309e",
"iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/",
"iat": 1388440863,
"nbf": 1388440863,
"exp": 1388444763,
"ver": "1.0",
"tid": "7fe81447-da57-4385-becb-6de57f21477e",
"oid": "68389ae2-62fa-4b18-91fe-53dd109d74f5",
"upn": "frank#contoso.com",
"unique_name": "frank#contoso.com",
"sub": "JWvYdCWPhhlpS1Zsf7yYUxShUwtUm5yzPmw_-jX3fHY",
"family_name": "Miller",
"given_name": "Frank"
}.
However, Google Cloud Endpoints only returns 3 fields (issuer, id, and email) as specified here: https://cloud.google.com/endpoints/docs/openapi/authenticating-users.
As you can see, there is misalignment in the fields, and perhaps some fields that would be valuable to have access to in the endpoints.
At this moment, X-Endpoint-API-UserInfo won't contain any additional info from claims than those documented (i.e. issuer, id, and email), however, the original JWT token itself is passed-through, so you can still extract the additional claims form there.
Related
I have written one custom policy in azure AD b2c and its working ok , Now i want to return the access token as well if some one login from social media account i am able to return access token but with local account login i am not sure what steps needs to follow , Can any one help me on this
login via social media: Claims like below works fine
{
"exp": 7676868,
"nbf": 6868712,
"ver": "1.0",
"iss": "xyxjhgjgjg/v2.0/",
"sub": "26cd4=jfh1-9e4f-4d74-a4bd-afjhhdfkj6",
"aud": "584nczac-f6ba-4d42-a051-859700f247cj,
"acr": "b2c_1a_signuporsigninwithphoneoremail",
"iat": 1622700jhj,
"auth_time": 1622700447,
"givenName": "mnmn",
"surname": "nbnbnb",
"name": "nbvnvnv",
"idp_access_token": "v117OqsDGUyPjPlqmjfRCZB7zrsWZBxfzhgj,mnn,lwIEuDVyvE3VsH4cuZAf",
"tid": "d302bdbnbvv-09e5-42bf-9006-6bjhgjg"
}
When you login via a social idp, the user enters their credentials on the social idp page, and in return gets an access token which B2C can use to grab their information after consent.
There is not the case for local accounts, because when the user logs in using a local account, they enter their credentials on the B2C idp itself. The access token is what constitutes these entire claims you have shared.
So in essence, when using social idp, there are two access tokens, one related to B2C, which constitute the entire claims, and another related to the social idp, which you highlighted in your question.
I want to use the AAD B2C Github identity provider to authorize users in my app. To create a user I need at least get an email from it - but I get nothing. I did set up everything according to docs and I can see in the AAD B2C Users list that Name is set up correctly for a new user, but User Principal Name where email should be is null
Here is JWT answer
{
"typ": "JWT",
"alg": "RS256",
"kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
"exp": 1611879546,
"nbf": 1611875946,
"ver": "1.0",
"iss": "https://apichat.b2clogin.com/4d39cd56-4c18-4bc7-aaa8-36bf91191c8c/v2.0/",
"sub": "dfe38752-113e-4431-b1bd-23dd53119369",
"aud": "341eea81-859c-485c-baea-2cc9f75f6512",
"nonce": "defaultNonce",
"iat": 1611875946,
"auth_time": 1611875946,
"idp_access_token": "c5c79a8f49c44575cf127fc3c64aaa5710a0a465",
"idp": "github.com",
"tfp": "B2C_1_susi_debug"
}.[Signature]
What do I missing?
Added
After some studying, I have a suspicion that the Github provider here either does not have the required scopes or mappings. I don't see any ways to add it so far. Potentially that might be solved by a generic OpenID Connect provider but Github does not support well-known/openid-connect-discovery and I have no option to manually set endpoints in AAD B2C.
So far I don't see any way to connect GitHub to my AAD B2C and get that darn email - why the biggest cloud platform does not fully support the biggest dev repository when they have the same owner is beyond my understanding.
Ok, the solution I found looks like that
Set Display Name and Identity Provider Access Token in Application Claims of your User Flow
On GitHub auth you will get name aka username and idp_access_token aka token
That's allow us to call github user api curl -u username:token https://api.github.com/user
By default user api returns public user profile, which might not have a set email
curl -u username:token https://api.github.com/user/emails will return all user associated emails
We need the primary one
{
"email": "***#gmail.com",
"primary": true,
"verified": true,
"visibility": "public"
}
I have an Angular Application which is authenticated using AAD B2C. This talks to a .Net Core API using an access token.
My problem is that I am not receiving a User Principal Name (upn) in my access token.
I have been adding additional "Application claims" like "Given name" and "Surname" and these appear in my access token just fine! Therefore, I believe that my scopes (openid, profile, email) are set correctly and that this in theory is working.
I believe since I am using version 1.0 of the token, that I do not need to configure an any additional claims in my application manifest. My user is a standard AD user not a guest.
The following document states that the upn claim should be included in the v1.0 tokens:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims
What am I doing wrong?!
Decoded Access Token:
{
"iss": "https://(my-tenant-name).b2clogin.com/(guid)/v2.0/",
"exp": (number),
"nbf": (number),
"aud": "(guid)",
"oid": "(guid)",
"sub": "(guid)",
"name": "My Name",
"given_name": "Given name",
"family_name": "Surname",
"country": "Norge",
"tfp": "B2C_1_signupsignin2",
"nonce": "(guid)",
"scp": "basic",
"azp": "(guid)",
"ver": "1.0",
"iat": (number)
}
UPN is not returned in AAD B2C tokens because it is an irrelevant random string that is set.
Rather AAD B2Cs unique name is stored in signInNames attribute, and returned in your token as email or username.
The doc you linked is for AAD, and irrelevant to AAD B2C. These are two seperate token issuer services. Select in your User Flow Application Claims to return “email addresses”.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-flow-overview#email-address-storage
At this time, apps that support both personal accounts and Azure AD (registered through the app registration portal) cannot use optional claims. However, apps registered for just Azure AD using the v2.0 endpoint can get the optional claims they requested in the manifest.
To achieve UPN Claim in the token, use B2C Custom Policy.
Refer this link for the starter pack: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
Add below claim to the TechnicalProfile AAD-UserReadUsingObjectId and in the Relying Party Policy (Eg: SignUpOrSignin.xml):
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
As per the code you have provided we observed you are using v2 endpoint( "iss": "https://(my-tenant-name).b2clogin.com/(guid)/v2.0/")
As per the document if you see iss:If the token was issued by the v2.0 endpoint, the URI will end in /v2.0.
In the V2 endpoint you need to make a request explicitly for UPN claim.
In v1.0 endpoint they are returned by default but v2.0 made smaller tokens so they made it optional.
Please go through the following links for more understanding. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims How to add optional claims in application manifest https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-app-manifest
I have an Azure AD application and have generated two client secrets. I can get a JWT access token using each secret (via client_credentials grant) but can I also see from the JWT token via which client secret it was requested?
If I inspect the JWT tokens I get back, some payload fields are always the same (aud, iss, etc) and some are always different (iat, nbf, aio, etc) but there is no info as far as I can tell that identifies the client secret that was used.
Here's an example payload:
{
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/e402c5fb-58e9-48c3-b567-741c4cef0b96/",
"iat": 1516886787,
"nbf": 1516886787,
"exp": 1516890687,
"aio": "Y2NgYEjJqF0stqv73u41a6ZmxPEvBgA=",
"app_displayname": "TravelAgencies",
"appid": "ee8cf944-bf6f-42cf-ae30-6060412416a1",
"appidacr": "2",
"e_exp": 262800,
"idp": "https://sts.windows.net/e402c5fb-58e9-48c3-b567-741c4cef0b96/",
"oid": "bc430bc6-d9fb-4fa0-87e5-8b8803fcb222",
"sub": "bc430bc6-d9fb-4fa0-87e5-8b8803fcb222",
"tid": "e402c5fb-58e9-48c3-b567-741c4cef0b96",
"uti": "1TgusyfGtECjErT0Kv4PAA",
"ver": "1.0"
}
On a related note: what are the aio, e_exp and uti fields for? I can't find any information on them.
You can't see through which client secret has the token been issued. What is the reason for asking through which secret it was?
Regarding provided claims - you can check here and here what the different claims mean. For exampe the iat, nbf are just dates - when the token was issued and the validity begin time.
For some of the claims, like aio there is no documentation. But there is no claim to show you which secret was used.
From https://learn.microsoft.com/en-us/azure/active-directory/develop/id-tokens
aio An internal claim used by Azure AD to record data for token reuse. Should be ignored.
This is a duplicate of how to validate token using outlook rest api, but that received no answers so I'm asking again.
I have managed to authorise a user and receive an access token. I will use the sandbox as an example.
I have decoded the access token and got the following:
Header
{
"typ": "JWT",
"alg": "RS256",
"x5t": "MnC_VZcATfM5pOYiJHMba9goEKY",
"kid": "MnC_VZcATfM5pOYiJHMba9goEKY"
}
Payload
{
"aud": "https://outlook.office.com",
"iss": "https://sts.windows.net/c512ffd1-581d-4dc0-a672-faee32f6387c/",
"iat": 1458918504,
"nbf": 1458918504,
"exp": 1458922404,
"acr": "1",
"amr": [
"pwd"
],
"appid": "32613fc5-e7ac-4894-ac94-fbc39c9f3e4a",
"appidacr": "1",
"family_name": "Dehenne",
"given_name": "Denis",
"ipaddr": "137.117.9.62",
"name": "Denis Dehenne",
"oid": "28328486-e820-4c98-a1cf-e8b35456313a",
"puid": "10033FFF89319A48",
"scp": "Calendars.Read Contacts.Read Mail.Read",
"sub": "XfYUvqiIreYX9wF-909Yf7Hodiwg6ClTwWOc75WmX7o",
"tid": "c512ffd1-581d-4dc0-a672-faee32f6387c",
"unique_name": "DenisD#oauthplay.onmicrosoft.com",
"upn": "DenisD#oauthplay.onmicrosoft.com",
"ver": "1.0"
}
Signature
gtpjf40FxEN8cTX22Mk-Da1n_sKtIUGAmzyYkuhkCskR5y1j4uuenf4ejJxeRwtqIIRWN5w1zOfvFZ2XqXreeSpSCZU-CJCoHIicchChUbyq4iIEcWZr29LbnpDkCyqB8LzoA3rEHUxhZYwHnWIHmkrD4XbMN4CW31bdNQwP0YgXvIucLe_tv80Eu4jDiZsqfCh91DFIb7bv6mbPXiTYMtV6OEdXeHLh--vFvZRRm--atSkKrZHFPT1no2B0YAC8w0kEYWPHyM-TbGni6WjIc7ZGSuDNmkHJfIKndcoFzlVJubV2ntKJhWrXfee490oj3GJi-lkNkFLfa9_VDIYu0w
Inside the Exchange identity token mentions something about metadata and self-signed X509 certificates, but those tokens include fields that don't exist of the ones I am getting.
The header states that the token is signed with RSA. I want to validate the token and for that I need the public key of the signing certificate. Where would I get the certificate? Do I even need to validate the token?
The token is issued by Microsoft Azure, not by Outlook or the Outlook REST API. I added the azure tag for you. According to the subtopic Validating Tokens:
At this point in time, the only token validation your apps should need to perform is validating id_tokens. In order to validate an id_token, your app should validate both the id_token's signature and the claims in the id_token.
We provide libraries & code samples that show how to easily handle token validation - the below information is simply provided for those who wish to understand the underlying process. There are also several 3rd party open source libraries available for JWT validation - there is at least one option for almost every platform & language out there.
It goes on to give more specifics. Like to get the signing key data:
You can acquire the signing key data necessary to validate the signature by using the OpenID Connect metadata document located at:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration