oAuth JWT resulting in Invalid Argument Error (400) - google-cloud-platform

I'm trying to enable account linking on my google action using oAuth2 code grant flow.
Unfortunately my linking fails in the last step. I think that I'm not returning the result of my /token endpoint correctly back to google.
I can see this response of a 400 error in my console after getting redirect to my actions page (/authorize worked fine):
Request URL: https://oauthintegrations.clients6.google.com/v1/token:getForService?key=api-key-removed-by-me&alt=json
{
"error": {
"code": 400,
"message": "\u003ceye3 title='/OpenIdConsumerService.ValidateOpenId, INVALID_ARGUMENT'/\u003e APPLICATION_ERROR;apps_auth/OpenIdConsumerService.ValidateOpenId;com.google.identity.accountlinking.error.FederatedProtocolException: \u003ceye3 title='INVALID_ARGUMENT'/\u003e OpenAuth::INPUT_ERROR: ;AppErrorCode=13;StartTimeMs=1602166359350;tcp;Deadline(sec)=59.962523136;ResFormat=UNCOMPRESSED;Originator=traffic-prod;Tag=\u0002cloud_project_number\u0003744920882961\u0002IncomingMethod\u0003/OAuthIntegrationsService.GetTokenForService\u0002cidc\u00032;ServerTimeSec=1.00669508;LogBytes=256;Non-FailFast;EffSecLevel=privacy_and_integrity;ReqFormat=UNCOMPRESSED;ReqID=2d3a46fa4ab8370e;GlobalID=c34268105821e185;Server=[2002:ab3:7310::]:4155",
"status": "INVALID_ARGUMENT"
}
}
This is the body I send back to google for /token (I guess this results in the error above):
{
"access_token":"jwt-token-here",
"expires_in":"1602162256000",
"refresh_token":"refresh-token-here",
"refresh_token_expires_in":"31535999",
"token_type":"Bearer",
"scope":"read"
}
Is the structure of the body correct? I think it's because of the jwt-token but when I decode it manualy everything looks fine.
Any help appreciated!
Thank you

Unfortunately my linking fails in the last step. I think that I'm not returning the result of my /token endpoint correctly back to google.
Just a quick note that your access/refresh tokens are opaque to Google. You are handing over these credentials for Google to pass back to you in future requests. What these tokens mean, and how they are determined to be valid, is up to your OAuth server implementation.
See the OAuth account linking guide for more details.
This is the body I send back to google for /token
The fields scope and refresh_token_expires_in are not parameters Google expects in your token exchange responses, so this is likely where the INVALID_ARGUMENT error is coming from. A basic token response to Google should looking something like this:
{
"access_token":"jwt-token-here",
"expires_in":"1602162256000",
"token_type":"Bearer",
}
The expires_in field refers to the access token and when Google should use the refresh token to request a new access token.
If you want to expire or rotate your refresh tokens, you can do that as well. However, you can't tell Google when a refresh token will "expire". To rotate refresh tokens, you have to pass back the new token the next time Google requests a new access token, such as:
{
"access_token":"jwt-token-here",
"expires_in":"1602162256000",
"refresh_token":"updated-refresh-token-here",
"token_type":"Bearer",
}
See the OAuth implementation guide for more details on the fields in the requests and responses.

Related

Postman 403 Token Issue

I am trying to get request with endpoint after successful login.
I achieved to be login and take the token but I could not take the list with this token. I am using postman. Whenever I click the url link i sent with token i can see the valid json with my safari.
{
"message": "Forbidden"
}
what i sent https://qo7vrra66k.execute-api.eu-west-1.amazonaws.com/products?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
How can I send and successfully take this request from postman ? Also I couldnt understand why postman don`t allow this like safari.
I tried your endpoint and got no error.

How does Postman handle localhost OAuth 2 redirects?

When using Postman to fetch an access token via Authorization Code, one of the fields I need to enter is for the Callback URL, aka the redirect URI query param when it's making the request to the authorization endpoint. I understand this URL needs to be registered/whitelisted within the OAuth provider, but my question is how does postman actually handle/intercept that request/redirect back when it's localhost-based? For example, if I already had a local server running on http://locahost:8090, and I told postman to use http://localhost:8090 for that callback, how does Postman end up seeing that request/redirect back (to exchange the auth code for an access token) instead of my local web server handling that request?
TL;DR: Postman basically ignores the callback URL when processing the response.
The Long Story
It does need it, but only for the request. As you say, it needs to be correct - exactly matching the IdP client application config - but that's it.
Postman is just helping you acquire the token, it doesn't need to provide it to the consuming application, which is the whole point of the redirect URL - a static path known by the client app and the OAuth client application that makes sure an evil website / intermediary doesn't steal tokens by abusing the redirection flows.
Since it's not meant to work on a browser on the internet, Postman can ignore the redirect. Once the IdP responds with the token then, as far as Postman is concerned, it's good to go. It can save the token in the local token store and use it to make API requests.
Implicit Flow
This is set up to get a token from an Okta endpoint:
When I click "Request token", Postman makes a request like this:
GET https://exampleendpoint.okta.com/oauth2/default/v1/authorize?nonce=heythere&response_type=token&state=state&client_id={the_client_id}&scope=profile%20openid&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fimplicit%2Fcallback
Postman pops a browser to make this request to the /authorize endpoint, at which the IdP then either creates the token (if the browser already has a cookie), or performs various redirects to authenticate the user and then create the token.
At the end of this flow, Postman will receive the 302 from the IdP that contains the token (on the location header). The target of that redirect is the redirect URL configured in the IdP:
302
Location: http://localhost:8080/implicit/callback#access_token=eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.{the_rest_of_the_token}&token_type=Bearer&expires_in=3600&scope=profile+openid&state=state
At this point Postman grabs the token from the #access_token parameter and it's good to go.
Auth Code Flow
Auth Code flow comes in 2 flavours:
Auth Code (Classic)
Auth Code + PKCE
Auth Code flow has been seen as "better" than the implicit flow because it requires a 2nd step in the process to get an access token. You hit authorize which gives the client a code and the code is then exchanged for the tokens. This code for token gives more chances for the server side components to do more stuff - extra checks, enrich tokens and various other things.
Q: Why are there 2 Auth Code flows?
A: The problem with this was that it required a server side component, which many SPA's and/or mobile apps didn't want to host. The endpoint that receives the code and gets the token(s) had to maintain credentials - a client id and client secret - which are required by the IdP when creating the token. PKCE is an extension that removes the requirement for a trusted server. It's adds computed hash to the /authorize call, which the IdP remembers, and then on the subsequent call to /token the client provides the source value of the hash. The server does the same computation, checks it's the same as that on the original request and is then satisfied that it's not handing out tokens to a bad guy.
Auth Code with PKCE
In terms of redirects, this is exactly the same as implicit. But for requests, it needs to make the second request to exchange the code for the tokens. The main differences here are
the access token URL, which is where to send the code and get tokens in response.
the code challenge and verifier, which are PKCE requirements for generating and computing the hash
The requests are now as follows:
The GET to /authorize
GET https://exampleendpoint.okta.com/oauth2/default/v1/authorize?nonce=heythere&response_type=code&state=state&client_id={client_id}&scope=profile%20openid&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fimplicit%2Fcallback&code_challenge=E7YtiHqJRuALiNL_Oc5MAtk5cesNh_mFkyaOge86KXg&code_challenge_method=S256
Postman will pop the browser (and the IdP will redirect it through login if required)
The eventual code response is also 302, however the location header contains the code rather than tokens:
location: http://localhost:8080/implicit/callback?code=J3RlQqW122Bnnfm6W7uK&state=state
So now the client needs to call the endpoint defined in the "Access Token URL" field to get tokens:
POST https://exampleendpoint.okta.com/oauth2/default/v1/token
Body:
grant_type: "authorization_code"
code: "J3RlQqW122Bnnfm6W7uK"
redirect_uri: "http://localhost:8080/implicit/callback"
code_verifier: "Fqu4tQwH6bBh_oLKE2zr0ijArUT1pfm1YwmKpg_MYqc"
client_id: "{client_id}"
client_secret: ""
And the response is a good old 200 that doesn't redirect - the authorize call sends the client back to the final redirect landing page, and the POST is just a normal request with the tokens on the the response
{"token_type":"Bearer","expires_in":3600,"access_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.*******","scope":"profile openid","id_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.********"}

POSTMAN Digest authentication not working

I am trying to access a REST API (Shopware to be specific), which is hosted externally.
When I log in to the frontend in the browser, I first need to enter a set of credentials in the browser authentication pop up. And then the application opens and I need to enter the application credentials.
I assumed the authentication for the API would also be similar.
This is how I see this set up: (sorry for the crude image) Set up pic
So first, I use HTTP Basic auth and pass my browser credentials to the server.
I get the following response:
{
"success": false,
"message": "Invalid or missing auth"
}
But in the Response header I get
Basic realm="<Realm B>", Digest realm="<Realm B>", domain="/", nonce="<nonce>", opaque="<opaque value>", algorithm="MD5", qop="auth"
Does this response mean that both Basic and Digest are supported for Realm B and the client can use any one of these?
I tried to authenticate again with Digest Auth chosen in postman,and using the realm B, nonce, opaque and qop values provided in the previous request.
But I still get a 401 Unauthorized error.
What am I missing? How does this two factor auth work via Postman?
Thanks in advance for your help.

Alexa Request Customer contact Access Denied

I am observing a very weird behavior in Requesting Customer Contact information, email in my skill's case.
I have implemented the exact same way as mentioned in the documentation. I have provided the permission in the skill's permission tab (for email). I have granted the permission in the app and from the code, I am calling the following REST API for fetching email id of the user by passing Bearer token (consent token in permissions object received in JSON input)
https://api.eu.amazonalexa.com/v2/accounts/~current/settings/Profile.email
But the weird thing is, that recently, I am getting this response
{'code': 'ACCESS_DENIED', 'message': 'Authentication failure with
reason: TOKEN_INVALID'}
I have been recently facing this issue that sometimes the API is working fine but sometimes, it is not and I am receiving the above errors.
Can anyone help please?
I am calling the following REST API for fetching email id of the user
by passing Bearer token (consent token in permissions object received
in JSON input)
According to this doc, consentToken has been deprecated, you should use apiAccessToken instead.
Important: Requests from Alexa may also include a consentToken within
session.user.permissions and context.System.user.permissions. This
property is deprecated. Existing skills that use consentToken continue
to work, but the context.System.apiAccessToken property should be used
instead.
Thus, accessToken = this.event.context.System.apiAccessToken.
Also, double-check your header: {"Authorization": "Bearer " + apiAccessToken}, make sure you have a space between Bearer and apiAccessToken.

Aws Cognito no refresh token after login

I'm using Amazon Cognito for authorization of my app.
I'm using the authorization code flow. I can successfully get my token on /oauth2/authorize?...
But I can't seem to successfully get access_token, id_token and refresh_token using the POST to /oauth2/token with the Content type header: application/x-www-form-urlencoded
and body:
{"key":"grant_type","value":"authorization_code"},
{"key":"client_id","value":"xyz"},
{"key":"redirect_uri","value":"redirect-url.com"},
{"key":"code","value":"code_from_previous_request"}
When I make this call I get the following error json:
{"error":"invalid_request"}
Client id is correct and client app has no secret.
Anyone has any idea what I'm doing wrong?
By taking a closer look a #MikePatrick's request I figured it out. I was sending a wrong parameter
redirect_url
instead of
redirect_uri
...
Note to self: Half of software bugs are caused by typos