I am trying to use GitLab (Self Hosted CE Edition) as OpenID Auth Provider. I am following https://docs.gitlab.com/ee/integration/openid_connect_provider.html#enabling-openid-connect-for-oauth-applications and https://docs.gitlab.com/ce/api/oauth2.html#gitlab-as-an-oauth2-provider to verify the flow manually.
I have created the GitLab App to generate Client ID & secret. I can also get the Authorization Code Successfully by hitting https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=YOUR_UNIQUE_STATE_HASH&scope=openid
I am also able to retrieve id_token(JWT) by calling POST on https://gitlab.example.com/oauth/token?client_id=ID&client_secret=SECRET&code=CODE&grant_type=authorization_code&redirect_uri=http://localhost
But when I decode the id_token on jwt.io, I am not able to see all the user profile claims mentioned on the docs link. following is the example JWT Payload I get {
"iss": "https://gitlab.example.com",
"sub": "768d4eeae122ca6655c9127487d9c4cd85b079796d35d33753b3c15b93486044",
"aud": "c3be56f955c74f0601683654df61ed3f74774902e2fb6da7ce05415b8a30e1d7",
"exp": 1521463699,
"iat": 1521463579,
"auth_time": 1521456265
}
Can anyone please help on how I can get various user profile attributes in the claims like email, name etc.?
I am using GitLab Community Edition 10.5.0 34d5766
Related
I am getting the following output from the /userinfo endpoint
{
"sub": "XXXX#gmail.com",
"aud": [
"XXXXXXXXX"
],
"nbf": 1646097620.000000000,
"scope": [
"openid",
"profile",
"email"
],
"iss": "https://XXXXXX/authServer",
"exp": 1646097920.000000000,
"iat": 1646097620.000000000
I need the username and the email to be visible.
Could any one help me on this ?
We are working on reference documentation, including how-to guides for cases such as this one. See How-to: Customize the OpenID Connect 1.0 UserInfo response #537, and feel free to up-vote that issue if it would be helpful to you.
In the meantime, check out the configuration in OidcUserInfoTests which demonstrates how to customize the claims returned by the User Info endpoint. For example, you can simply map all of the claims from the JWT (access token), or you can map only specific claims.
You may also be interested in seeing the DefaultOidcUserInfoMapper. The default strategy used is to map the standard claims from the id_token that are resolvable by the granted OIDC scope(s). Since in your example, you have profile and email, you can also provide an OAuth2TokenCustomizer to add the associated claims to the id_token when it is created, and they will automatically show up in the User Info endpoint. See OidcTests for an example of customizing the id_token.
I am trying to secure APIM APIs using OAuth2 via AzureAD by reading the article: Protect a web API backend in Azure API Management by using OAuth 2.0 authorization with Azure AD
AzureAPIM - OAuth2
Authorization endpoint URL (v1): https://login.microsoftonline.com/{tenant}/oauth2/authorize
Token endpoint URL (v1): https://login.microsoftonline.com/{tenant}/oauth2/token
Client ID: client-app id
Redirect URI: (deprecated portal): https://xxx-api.portal.azure-api.net/docs/services/auth1/console/oauth2/authorizationcode/callback
AzureAD - backend-app:
scope: Files.All
AzureAD - client-app:
secret key: xxx
Redirect url: ONLY WORK with deprecated portal in APIM (https://xxx-api.portal.azure-api.net/docs/services/auth1/console/oauth2/authorizationcode/callback)
For Demo Conference API, Add Validate JWT policy to Inbound processing where 3a0cf09b- is tenant id and b7c31179- is backend-app application id:
In Developer portal, the authentication to AzureAD is successful with a return token:
However the authorization is failed with calling the API:
Inspecting the received token in jwt.io, I found that the "aud": "00000003-0000-0000-c000-000000000000" is not backend-app application id:
{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/3a0cf09b-xxx/",
"app_displayname": "client-app",
"appid": "05a245fb-xxx",
"scp": "Files.Read User.Read profile openid email",
"tenant_region_scope": "OC",
"tid": "3a0cf09b-2952-4673-9ace-0e1bf69ee23a",
"unique_name": "user1#xxx.onmicrosoft.com",
}
API Test HTTP response trace shows the error on validate-jwt:
validate-jwt (-0.138 ms)
{
"message": "JWT Validation Failed: Claim value mismatch: aud=b7c31179-xxx.."
}
Replacing aud by the value in the token 00000003-0000-0000-c000-000000000000 or removing the required-claims in the validate-jwt policy to get it working.
Any idea please?
From your error report, it is indeed a 401 error, that is, your aud does not match the api you want to call, I use the auth code flow to do a simple demonstration for you:
First expose the api of the back-end application and add the client application.
Next,under 'API permissions', give your front-end application access to your backend api:
Under 'API permissions' click on 'Add permission', then click on the 'My APIs' tab.
Find your backend application and select the appropriate scope.
Click 'Add permissions'.
Grant admin consent for your APIs.
Get token:
Parse the token：
It seems you choose v1 endpoint of OAuth2 authorization but not v2 endpoint, so the value of aud in access token should be like b7c31179-xxxx.... but not api://b7c31179-xxxx..... So there are no mistakes in your steps of get access token.
According to some test in my side, the cause of this problem is you did not specify a parameter resource with the value of the backend-app application id when you configure OAuth2.0 in your APIM. The document you refer to also mentions this (I test with not specify this parameter, it shows same problem with yours)
So to solve this problem, please go to your APIM and click "OAuth 2.0" tab, edit the item you created. Add a parameter resource with value of the backend-app application id.
Note: When you add the parameter resource and click "Save" button, please open the item again and check if the "Client secret" box is empty. When I test in my side, the "Client secret" box shows empty after add parameter resource, it may be a bug on that page. If "Client secret" is empty, it might show error message like The request body must contain the following parameter: 'client_assertion' or 'client_secret' when you get the access token in Developer portal.
I believe I am missing something with the implicit grant process and access tokens in aws cognito.
To this point:
Have a user pool, with a client app configured for implicit flow and scopes openid, profile, aws.cognito.signin.user.admin
Used a stack overview and the official documentation and older white papers to achieve:
Login process that redirects to aws cognito UI, and back to my app, with tokens and other information in the fragment portion of the URL.
The access_token value parses at jwt.io and signature checks out using the aws jwt tool
Problem:
The recommended step is to "verify that the access token belongs to us" through the tokeninfo api call.
When I attempt to call tokeninfo via javascript code and testing via postman (using: https://api.amazon.com/auth/o2/tokeninfo?access_token=eyJraWQiOiJoVFBa... )
I get the result:
{
"error_description": "The request has an invalid parameter : access_token",
"error": "invalid_token"
}
and an http header:
x-amzn-errortype: InvalidTokenException:http://internal.amazon.com/coral/com.amazon.panda/
Variants I have tried:
I have tried calls directly to the user profile (using Authorization header, and query string and x-amz-access-token header).
I have tried adjust parameter names (error becomes "access_token required" or something like that
I have tried adjusting scopes in the user pool
I have tried adding resource servers (though I am not there yet...)
The redirect after login looks like this:
https://staging.example.com/loginresult.html#id_token=eyJraWQiO<tokenremoved>&access_token=eyJraWQiOiJoVFBa<tokenremoved>&expires_in=3600&token_type=Bearer&state=whateverdevwants
The parsed values of the token (through jwt.io) are:
{
"sub": "5510a27d-ebcb-4883-8680-a66fd0462279",
"token_use": "access",
"scope": "aws.cognito.signin.user.admin openid profile",
"iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_OF5OOfdx0",
"exp": 1519352461,
"iat": 1519348861,
"version": 2,
"jti": "31950a91-e2a5-4060-8c31-977f49802d35",
"client_id": "3iuhnprmod0josge24ogarecfp",
"username": "5510a27d-ebcb-4883-8680-a66fd0462279"
}
Update: As answered below: just don't do this, it is conflating jwt tokens from cognito with whatever "Login With Amazon" was using.
In the example you refer to from Amazon they encode the access token using urllib.quote_plus for example in their PHP example.
Make sure you are URL encoding the access token too in your javascript code with encodeURI.
Also an error may be returned if the token has expired so make sure you verify a newly-minted token. Expiry is 3600 seconds - so make sure the token is less than an hour old.
EDIT
Looks like the documentation for Cognito is very different from the LWA (login with amazon) auth flow. The tokens in the examples you linked to aren't even JWT tokens!
The Cognito documentation here explains how to verify the JWT token.
Checkout the Using ID Tokens and Access Tokens in your Web APIs paragraph.
I create Backend server, which gets the ID Token from mobile application (iOS). How can I verify that this token is OK and can be used it securely?
Official Google's documentation about validating token:
https://developers.google.com/identity/protocols/OpenIDConnect#validatinganidtoken
It recommends to verify the ID Token locally, without sending verification request to the Google. Is it OK to check some fields from ID Token locally like in documentation or maybe should I send some request to Google to verify token as well?
Google documentation mentions about debugging and verifying ID Token with:
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123
But it doesn't recommend to use it in production. I thought also about using Access Token along with the Id Token and verify Access Token first with:
https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=
But does it make the whole process of validating client's credentials (mobile app, web app) more secure?
Fist let me start by saying I don't work for Google. However I have been developing with Google Oauth2 since 2012. A while back I asked a Googler just this question.
His recommendation was if you have a refresh token just request a new access token. If its bad the server will return an error. If you have an access token send a request if its bad the server will return an error.
There isn't really much point in validating it first your just sending two requests to the server for every request you make. All you will be doing is preventing errors on a small percentage of the requests you are making in the long run.
I have never bothered with the id token. Id token is a jwt so you should be able to open it I think.
update
You should consult Verifiy the integrity of the id token.
You can also do some checking on your own. The id token is a jwt if you decrypt it you get or by calling the tokeninfo endpoint
{
"iss": "https://accounts.google.com",
"azp": "407408718192.apps.googleusercontent.com",
"aud": "407408718192.apps.googleusercontent.com",
"sub": "11720055326",
"at_hash": "HQVaIRLqmsjaTt8KoOIQ",
"name": "Linda Lawton",
"picture": "https://lh3.googleusercontent.com/a-/AAuE7mDuIWqXzrrp-65cIhXSD2HjCI8WYsWHR0fDx5_wQPY=s96-c",
"given_name": "Linda",
"family_name": "Lawton",
"locale": "en",
"iat": 1567751,
"exp": 1567755
}
iss should be https://accounts.google.com
aud will be the client id of your app 7408718192.apps.googleusercontent.com
at_hash there may also be some way to validate against this but i haven't bothered
I have ADAL for iOS working with an ADFS 3.0 server. It brings up a web view, the user authenticates and I get a call back with an access token.
The problem I have is that I get no information back about the user's identity. The userInformation property is nil. There's no id_token in any of the HTTP responses and I'm not sure how to request one in the first place. And I've seen elsewhere the Microsoft folks say that ADFS 3.0 doesn't support id_token at all. I've also parsed the JWT formatted access token and there's no information in there either that I can use to identify the user.
On the ADFS 3.0 server side, we have configured and enabled a Claim Rule that says to provide the relying party with GUID, Given Name, Surname, and Email Address. But adding that rule made no difference in the responses I get through ADAL.
How can I identify a user (i.e. get a GUID, first name, last name and email address) who was authenticated via ADAL against an ADFS 3.0 server? Is there an endpoint on the ADFS 3.0 server that I can hit with the provided access token where I can request this information?
It turns out that ADFS 3.0 may not support id_token, but if you have the Claim Rules for the Relying Party set correctly they will be added to the top level of the access token you receive. Apparently the claim rule should look something like this when it is correct:
The access token is a JWT token so it can be decoded and the values retrieved from it there. When decoded, it will look something like this:
{
"appid": "5f9a5589-6064-423a-8a1a-6a0d7ddda19f",
"aud": "x-msauth-glazersapp://com.example.MyApp",
"auth_time": "2016-08-08T22:32:14.459Z",
"authmethod": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
"email": "me#example.com",
"exp": 1470699134,
"family_name": "John",
"given_name": "Doe",
"iat": 1470695534,
"iss": "http://adfs.example.com/adfs/services/trust",
"objectGUID": "c8oMVOOEskutnPVno41Y1w==",
"ver": "1.0",
}
"email", "family_name", "given_name" and "objectGUID" were added to the access token. And watch out, the GUID when provided like this is actually Base64 encoded.
More information available here: http://chrisrisner.com/Accessing-Resources-Secured-By-Azure-Active-Directory-with-iOS-and-Android