I have an api with oauth2.0 authorization grant type authentication which has the following steps -
Get method for authorization code which opens up a form in browser where you need to enter credentials. This results in a series of post redirect requests and finally returns a authorization code in third post response header
Now a post request is sent, with grant type authorization code containing client credentials and the above authorization code we got from the get request, in the body and it returns the access token
This is how it works in postman. How can I achieve the same thing using Rest Assured?
You need two handlers
Handler 1:
To redirect to oauth server. (requeter should identity list of grant types, generate url with client_id and state and redirect application to this url)
Once end user signs in and allows the grant. (assumed that user allows)
Handler 2:
oauth server redirects back to postman with a authorization_code and state.
You need to configure redirect to your server callback url.
Once you receive these two
Verify state is same as what you sent. if yes proceed.
send authorization_code, cleint_secret, client_id back to server to recieve access_token and refresh_token
Use access_token to access data.
Use refresh_token to get new access_token.
Related
Friends, in the Authorization code flow, it states that after the /authorize call is initiated and success, the authorization code will be sent via HTTP 302 "redirect" URL to the client(say ReactJS webapp). Why the OAuth specification requires this to be sent in a redirect so the authorization code is sent in URL parameters exposed. I know it is recommended to use PKCE to handle this auth code leak issue, but my question is why OAuth spec requires us to send the auth code in 302 redirect in URL params in the 1st place. Why cannot the client(ReactJS webapp) place a simple GET request to the IDP and why cannot the IDP send back the auth code in the response body to the react JS application(say by xmlhttprequest). Any help is appreciated. Thanks.
If you use a OAuth2 service like Google, or some other service, and your react application would be able to handle the entire flow it means it can completely act on behalf of the user.
By requiring a redirect, it means that the user's own browser will go to the auth service's website, which is the only place the user can trust to safely enter their password and grant access to your application.
The URL in the addressbar means trust. Users are trained to never enter their password in a website they don't recognize.
I have set up a Cognito authorizer with an App client that is connected to Google Identity Provider.
"Callback URL" is http://localhost and "Sign out URL" is http://localhost/logout. I have enabled the "Authorization code grant" and the "Implicit grant" flows and the I want to implement the following flow :
User sends a GET request to the LOGIN endpoint (/login) which is the following:
https://mycognAuthorizer.auth.eu-west-1.amazoncognito.com/login?client_id=MYCLIENTID&redirect_uri=http://localhost&response_type=code
User sends a POST request to the TOKEN endpoint (/oauth2/token) with the following parameters
POST https://hocublen.auth.eu-west-1.amazoncognito.com/oauth2/token
Content-Type='application/x-www-form-urlencoded'
grant_type:authorization_code&
client_id:<MYCLIENTID>&
redirect_uri:http://localhost&
code:<CODE_FROM_LOGIN>
Where <CODE_FROM_LOGIN> is the code returned by /login endpoint on the first step.
My problem is that the first endpoint (/login) works fine and I get the code, but the second endpoint always returns a Bad Request response with an "invalid client" message.
Is there something that can be missing from the configuration?
Also, if I choose to ask for a token from the login endpoint instead of a code, is this token equivalent with that of the TOKEN endpoint?
It seems that when one creates an AppClient the "Generate client secret" is enabled by default, but in subsequent views of the AppClient, one has to press show details to see that the password is set and what the password is.
For the scope of my needs, I just removed the password.
Invalid client is occured when you're generating client_secret for your app clients. You should add your client_secret in your request.
I'm integrating Okta to my own IdP server by using Okta's API.
I'm implementing the Authorization code flow by following the steps below:
In my own server, use the /api/v1/authn endpoint to get the sessionToken.
Use the sessionToken to obtain the authorization by calling this endpoint: /oauth2/v1/authorize?client_id=" + clientId + "&sessionToken=" + sessionToken + "&response_type=code&response_mode=query&scope=openid&redirect_uri=" + redirectUrl + "&state=evanyang&nonce="
It's supposed to return a response with status code 302 and with the Location header containing the redirect url as well as the code value.
However, I keep getting a response with status code 200 and without the Location header, with a html body saying "You are using an unsupported browser." and "Javascript is disabled on your browser."
According to the API documentation: http://developer.okta.com/docs/api/resources/oidc.html#authentication-request, the sessionToken parameter is sufficient to do this: An Okta one-time sessionToken. This allows an API-based user login flow (rather than Okta login UI).
Am I missing any extra requirement for getting the authorization code through API? Please help.
Thanks in Advance :)
The Authorization Code grant type and the Authorization endpoint in there are meant to be access through a browser, not a non-browser client.
This issue is caused by obtaining session id between obtaining session token and authorization code. Once the session token is used to get session id, it becomes invalid, which means it cannot be used to get authorization code anymore.
According to Okta, the Authorization Code grant type and the Authorization endpoint and be used through a API-based web app too, as long as the session token is provided in the request: http://developer.okta.com/docs/api/resources/oidc.html#authentication-request. In fact, one can use this script(https://github.com/SohaibAjmal/Okta-OpenId-Scripts) to finish the flow.
I am trying to exchange the authorization code I received without success. I am using the manual way where I omit the redirect url:
https://api.dropbox.com/oauth2/authorize?response_type=code&client_id=<key>scope=&state=<state>
when this url is activated it will take the user to the authorization screen, if the user authorized the app, it DOES NOT redirect, instead it prints an authorization code such as:
Enter this code into <app-name> to finish the process.
GooKWtwe54AAAAAAABABSUl_Ruv1COvpBBCuWQ5kv2g
How do I exchange this code for an access token?
If you're not supplying a redirect_uri parameter on /oauth2/authorize to automatically redirect the user, you can prompt them to copy that authorization code into your app manually. Then, your app should exchange that authorization code for an access token using /oauth2/token.
Also, note that /oauth2/authorize should be accessed on www.dropbox.com not api.dropboxapi.com, as it is a web page. The /oauth2/token endpoint is an API call, so that should called on api.dropboxapi.com.
You can find the documentation for both of these here:
https://www.dropbox.com/developers/documentation/http/documentation#authorization
We are using App Service Authentication to protect a web API and using Google as authentication provider. It works as expected when we fire a request from a browser (when the session information is in the cookie)
IIS log:
2016-05-29T13:51:19 PID[3600] Verbose Received request: GET
https://XXXXXX.azurewebsites.net/api/user 2016-05-29T13:51:19
PID[3600] Verbose Found 'AppServiceAuthSession' cookie for site
'XXXXXX.azurewebsites.net'. Length: 728. 2016-05-29T13:51:19
PID[3600] Verbose Authenticated XXXXXX#gmail.com successfully
using 'Session Cookie' authentication.
But when we use API testing tool such as Postman and set the Authorization header with bearer token, it always results in redirection.
IIS log:
2016-05-29T13:53:38 PID[3600] Verbose Received request: POST
https://XXXXX.azurewebsites.net/api/user 2016-05-29T13:53:38
PID[3600] Information Redirecting:
https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=XXXXXXX-XXXXX7attpunn9smo4.apps.googleusercontent.com&redirect_uri=https%3A%2F%2FXXXXXX.azurewebsites.net%2F.auth%2Flogin%2Fgoogle%2Fcallback&scope=openid+profile+email&state=nonce%3De5f4aabe11cb4544bf18d00920940d47_20160529135838%26redir%3D%2Fapi%2Fuser
We also tried to set X-ZUMO-AUTH header with the same bearer token, we see error as the token is not in expected format. Apparently it expects encoded JWT token.
IIS log:
016-05-29T13:51:52 PID[3600] Verbose Received request: POST
https://XXXXXX.azurewebsites.net/api/user 2016-05-29T13:51:52
PID[3600] Warning JWT validation failed: IDX10708:
'System.IdentityModel.Tokens.JwtSecurityTokenHandler' cannot read this
string: 'Bearer
ya29.XXXXXXXXXX_RDrX_zsuvMx49e_9QS5ECz9F1yhDHe5j4H9gRN6opkjLXvN1IJZjHXa_Q'.
The string needs to be in compact JSON format, which is of the form:
'..'.. 2016-05-29T13:51:52 PID[3600]
Information Redirecting:
https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=XXXXXXX-k5nj6dkf987attpunn9smo4.apps.googleusercontent.com&redirect_uri=https%3A%2F%2FXXXXXX.azurewebsites.net%2F.auth%2Flogin%2Fgoogle%2Fcallback&scope=openid+profile+email&state=nonce%3De15b0915406142378XXXXX_20160529135652%26redir%3D%2Fapi%2Fuser
Note:
Bearer token obtained from Google is valid as we can verify the detail by making call to
https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=[token]
Please suggest.
The Google token you're using is an access token, not a bearer token. It can be used to access Google resources but cannot be used to authenticate with your Web API.
I wasn't able to find good documentation on this, but I can tell you it works here instead:
In your client app, you must obtain an id_token and an authorization code from Google. You normally get this when the user logs in using the Google OpenID Connect login. I assume you already know how to do this since you already know how to get the access token.
Send a POST request to https://{hostname}/.auth/login/google with a JSON payload that looks like {"authorization_code":"<code>", "id_token":"<id_token>"}.
A successful login response will contain a JSON payload that contains an authenticationToken field. Cache this token.
You can use the authentication token from #3 to make authenticated calls to your web API. Put it in the x-zumo-auth HTTP request header.
Turn on Authentication / Authorization from App Service Portal
Browse to the web app or API that requires authentication, you will be redirected to google login page, when you authenticate successfully, the response will contain:
"id_token": this token can be extracted from the response, or by accessing the Token Store /.auth/me
"redirect_uri" this token will be included in the response body, also you can just set it statically in the following step since this is the callback URL and it shouldn't change unless you change it from the google console
POST a request to https://{hostname}/.auth/login/google with the following JSON payload, {"redirect_uri":"", "id_token":""}. a successful response will contain "authenticationToken" store this token or cache it
Subsequent requests to the APIs that requires authentication should contain an HTTP request header:
"x-zumo-auth" with the value of "authenitcationToken"
Bonus:
In order to verify your token you can POST to https://{hostname}/.auth/login/google with the following JSON pay load {"id_token":""}, the response should specify if the token is valid or not