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.
Related
A number of our users authenticate through the Google OAuth API (https://developers.google.com/+/web/api/rest/oauth)
What is the future of the Google's version OAuth API beyond the April 2019?
OAuth aside, we use the following endpoint to obtain the user's email and name: https://www.googleapis.com/plus/v1/people/me once we obtain the access token. Is this endpoint becoming obsolete?
Update 12/21/18
Google+ Shutdown Notice
[End Update]
OAuth 2.0 is a service provided by Google Accounts. The end of life for Google+ will not affect OAuth 2.0.
OAuth 2.0 is the foundation authentication service for Google Cloud Platform, G Suite and many other services. OAuth 2.0 is token based, and these tokens can be used on a variety of services, both Google based and third party.
A further question was asked below in the comment section about endpoints.
The Google+ endpoint for user information: googleapis.com/plus/v1/people/me will probably continue to exist for years (awaiting official announcement from Google).
I would start using the Google OAuth 2.0 endpoint (notice the alt=json): https://www.googleapis.com/oauth2/v3/userinfo?alt=json
Which returns Json that looks like this:
{
"id": "123456789012345678901",
"email": "username#example.com",
"verified_email": true,
"name": "User Name",
"given_name": "User",
"family_name": "Name",
"link": "https://plus.google.com/123456789012345678901",
"picture": "https://lh3.googleusercontent.com/.../mo/photo.jpg",
"locale": "en",
"hd": "example.com"
}
The current list of Google OAuth 2.0 endpoints:
https://accounts.google.com/.well-known/openid-configuration
What is the future of OAuth API beyond the April 2019?
Oauth is not an api it is a protocol for authentication. In this instance the authentication response is used to access googles APIs. Googles use of Oauth2 for authentication is not going any where there has been no announcement that it is being discontinued in any way. Nor do i think they would as to my knowledge it is current industry standard for authenticating to APIs
OAuth aside, we use the following endpoint to obtain the user's email and name: https://www.googleapis.com/plus/v1/people/me once we obtain the access token. Is this endpoint
The Google people api may contain the term plus in the url but it does not really have anything to do with Google plus (other than really bad naming).
[Documentation] The People api lets you list and manage the authenticated user's Contacts and retrieve profile information for authenticated users and their contacts.
Which actually has nothing to do with Google plus other than the fact that some of the users profile information may have originally been contained within Google plus which has now been moved i suspect (but i have no proof of that). I did send off an email to google asking for some clarification as to exactly which endpoints are shutting down.
Shutdown
So what is going to happen with the shutdown
Google+ will stop working
plus.activites will stop working.
plus.comments will stop working
What will happen to people overview will be a really good question. They may be renamed however i suspect they may just be left alone to access the google contacts as they do currently. (again i have no proff of this)
Get current user info
If you want to get the information about the current user then an idea would be to use the userinfo endpoint. As long as you requested the profile scope you can request the current users info from the identity server directly
Request:
GET /oauth2/v2/userinfo HTTP/1.1
Host: www.googleapis.com
Content-length: 0
Authorization: Bearer qMgWQHD0MstTDVip7hIYipUpSQkxexF4-W0bI3geEaYk0ztVryYZyFRrZDFWkn69Hw3RlBjfOuXJ8df_iv5ATgW3y0BUkI0xMXeGq22qmfqG-4duSU
Response:
{
"picture": "https://lh5.googleusercontent.com/-a1CWlFnA5xE/AAAAAAAAAAI/AAAAAAAAl1I/UcwPajZOuN4/photo.jpg",
"name": "Linda Lawton",
"family_name": "Lawton",
"locale": "en",
"gender": "female",
"link": "https://plus.google.com/+LindaLawton",
"given_name": "Linda",
"id": "117200475532672775346"
}
I suspect that some of this is going to change. Link for example is not going to be able to link to google plus anymore. I think i will send off an email to google to see what they intend to do about that.
Email will only appear in the response if you have also requested email scope when authenticating the user.
update
blog post on api shutdown just went out and gives information on what APIs are being shut down and when.
The most commonly used APIs that are being shut down include:
Google+ REST API
Google+ Web API
Google+ Android SDK
Google+ Domains API
Google+ Pages API
This still doesn't clear up the issue with the people API being Google contacts yet part of the Google+ rest API
https://developers.googleblog.com/2018/12/google-apis-shutting-down-march-7-2019.html?m=1
In order to disable this Google + API from your apps, you need to go to https://console.developers.google.com
... and navigate to each project you are using Google+ Api and click DISABLE
This will remove any requests from Google + API.
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
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