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
Related
I am making a web application. Front side is react, server side is rails api and I use firebase authentication.
Now, I get firebase token and set authorization header whenever calling rails api as below.
client.interceptors.request.use(
async (config) => {
config.headers['Content-type'] = 'application/json'
config.withCredentials = true
var token = await firebaseApp.auth().currentUser?.getIdToken()
config.headers['Authorization'] = `Bearer ${token}`
return config
},
(error: AxiosError) => {
throw new Error(error.message)
}
)
But, I found some ways to store token, unsafe local storage, http only cookie.
Why need front end stores firebase token? Is it bad to get the token every time calling rails api?
Firebase ID Tokens are basically JWT, signed by Firebase.
Now imagine a scenario where you need to identify the user in your server. You will probably pass the user's UID in the HTTP Request, which is not safe as that can be easily bruteforced unless you have some sort of rate limiting in your server.
What I meant by signed?
A JWT looks something like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
The data stored in above JWT is:
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
You need to verify those Firebase IDTokens using Firebase Admin SDK. I don't know if that works with Ruby but worth checking the link above.
Verifying those will either return an object with user auth info or an error if that is an invalid JWT.
You must always pass this JWT in you REST requests to your server because these cannot be bruteforced. Anyone can make a JWT (IDToken) with same content but they don't know your signature. They will need your Firebase Service Account credentials to do so.
Also, JWTs expire eventually (I assume after an hour). So it's not bad to get token again and again. That's what they are meant for. Short term access.
I recommend you to watch this JWT Tutorial.
Just be sure to pass the idToken to your REST API to authenticate users and not their UID.
When I try to access Rounaz Cricket API, server send me back
{
"data": null,
"status": false,
"status_code": 403,
"status_msg": "AccessDenied",
"version": "2.0.2"
}
I get access key from my app and hit auth api and get access token
my API is:
https://rest.cricketapi.com/rest/v3/players_list/?access_token=xxxx&board=india&competition=international-t20&year=2018
The response would indicate an issue with your access token. Perhaps it has expired, or there is another issue with your account.
Presumably this is the documentation you used to generate the access token?
https://www.cricketapi.com/docs/Core-API/Auth-API/
I would try to generate a new access token, although if that continues to fail, the cricketapi.com support might be a better place to obtain a solution. Especially if its account related.
I want to reuse the OAuth2 client-secret of a Google Apps script project to access Google APIs on behalf of this script (e.g. via Sheets API reading a spreadsheet where the script has access). Users with a Google account granted the necessary scopes to the script. Now I'd like to replace the script with a new app without asking the users again for user consent. Typically, when the script (or the app) runs the users would be offline.
My first question would be, if this scenario is a supported OAuth2 use-case with Google API authorization, and if so, what would be the best way to implement it, especially to prevent security issues?
Client secrets of the script
OAuth2 client-secret file of the script from Google API Console, under Credentials. Also see Credentials, access, security, and identity and Setting up OAuth 2.0
The client-secrets.json looks like this:
{"web":{
"client_id": "57...1t.apps.googleusercontent.com",
"project_id": "project-id-95...70",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_secret": "K2...y1",
"redirect_uris": ["https://script.google.com/oauthcallback"]
}}
The file would be deployed with the app code (App Engine). But an alternate location such as Cloud Storage would be possible.
OAuth2 access token
In absence of the user, I would like to use the client ID and secret with the same scopes that were granted to the script originally, for getting an access token from the Google authorization server, something like this:
HTTP 200 OK
Content-type: application/json
{
"access_token": "987tghjkiu6trfghjuytrghj",
"scope": "foo bar",
"token_type": "Bearer"
}
I would like to use the access token in the HTTP Bearer header for the requests to the Sheets API on behalf of the old script.
Client_credentials request to authorization server
My (limited) understanding is, that I can use the grant-type client_credentials to get the access token from the authorization server. The request would look like this:
POST /o/oauth2/token
Host: https://accounts.google.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Authorization: Basic Base_64_string
grant_type=client_credentials&
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fspreadsheets
Where the Basic HTTP authorization is client_id:client_secret values, separated by a colon, and base64 encoded.
If I ditch grant_type or scope in the body, I will get corresponding errors.
The version as above resulted in: {\n "error" : "invalid_request"\n} response, no specifics provided. I have tried with client_id and client_secret in the body in combination with and without the Authorization header, all with the same error.
First Off let me start by saying that i am not an expert in app script or sheets i have used both a few times but i dont consider myself an expert in the subject.
When you authenticate someone their authentication is granted based upon the client id from within a project. They are granting you access to their data and approving the credential request. Think of it as a recored in Googles database someplace.
User 321 has granted consent to client 123 to access their sheets data.
So you have a project Super Script App which has client id 123 you are asking for access to edit sheets. If i approve it i am giving Super Script App with client id 123 access to my sheets. While i am sitting at my machine your app will run accessing my data. Now when i log off Super Script App with client id 123 cant access my data unless you have offline access and have a refresh token. With that refresh token you will be able to access my data when i am not there by requesting a new access token.
Now you want to make a new app. If you take the client id 123 and use it in your new app I am going to have to login to my google account but it will not popup and request that i give you permissions to access my data I have already granted client id 123 access to my sheets. Unless you have a refresh token your not going to be able to access this data without me being there.
If at anytime you ask for an extra scope I am going to have to approve that.
Now comes the fun part. I haven't actually tried this in a while. If you go to Google Developer console and create client id 321 under the same project as client id 123, and then use that in your new Super Script App V2 will i still have to grant it permission to access my data? I am going to lean towards probably not. Note a refresh token created with client id 123 will not work with client id 321 they are locked to a client unless its mobile and there is some magic their.
I am not exactly sure what you are doing with your second app so i hope this helps clear things up.
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 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