I was trying to write an UWP App in c++ (Visual Studio) for OAuth in to Google Drive API.
I referred the notes from this project under Github -
https://github.com/googlesamples/oauth-apps-for-windows/blob/master/OAuthUniversalApp/README.md
I was able to get the Authorization code from Google. But when I used the Authorization code to request for Authorization token then it is throwing me an error 404.
My Authorization token request URI looks like this -
https://googleapis.com/oauth2/v4/token?code=XXXXXXX#&client_id=ZZZZZZ&client_secret=YYYYYY&redirect_uri=uwapp.testgoogleoauth:/oauth2redirect&grant_type=authorization_code
Going by the notes mentioned in the link, I created the client ID using iOS application type. But I didnt get the client secret key at that step. I had to explicitly generate the client secret key again for the iOS application type.
Is there any issue which you see in the request URI being sent for the Authorization token request? What should be the value of client_secret to be used if the type of client has been selected as iOS in google console?
Thanks,
/vikas
Is there any issue which you see in the request URI being sent for the Authorization token request?
In you request URI you are using https://googleapis.com/oauth2/v4/token. However to make the token request, the correct token endpoint should be:
https://www.googleapis.com/oauth2/v4/token
And this is the reason why you get 404 (Not Found) error.
What should be the value of client_secret to be used if the type of client has been selected as iOS in google console?
In Handling the response and exchanging the code, we can find that
client_secret The client secret you obtained from the API Console (not applicable for clients registered as Android, iOS or Chrome applications).
So for iOS clients, there is no need to use client_secret. And as UWP is similar to iOS, we can also ignore this field in UWP.
The complete authorization token request might look like the following:
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
code=XXXXXX&
client_id=ZZZZZZ&
redirect_uri=uwapp.testgoogleoauth:/oauth2redirect&
grant_type=authorization_code
Related
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.********"}
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.
This page claims that you can access the Places Graph functionality without having a logged-in user:
You make your calls using a Client Token (from the client), and an App Access Token (from the server).
The documentation regarding Client Tokens says:
The client token is an identifier that you can embed into native mobile binaries or desktop apps to identify your app. The client token isn't meant to be a secret identifier because it's embedded in apps.
This sounds like exactly what I want--I am trying to build a website that allows users to search for Facebook places. I need to be able to build the list using an AJAX request from the client side.
I can't for the life of me find any documentation on using the Client Token to make such a request.
Please note that I cannot use an App Token because this will be deployed to a website, and Facebook specifically says not to use App Tokens in that context.
I've tried using the Client Token directly as the access_token, but then I get Invalid OAuth access token.
How can I use the Client Token to make a Places Graph API call directly to Facebook's API from the client's browser?
Note: I realize that I could send the request to my own server, then relay that request from my server to Facebook, but that is not an optimal solution for me.
In case anyone is still struggling with this like I was. You just need to use the appId and client token joined with a pipe. So "appId|clientToken".
Is there a way to authenticate the Microsoft or google OAuth token in active directory without using an authentication server?
Here is the scenario:
A client app gets an Microsoft access_token from some external service.
Client app will make a call to some secured web API and pass that access_token along with the request header
If the access_token passed by client is valid then API will provide response to the client.
Is there a way to validate that access_token on API side?
My normal understanding about OAuth 2.0 is there needs to be an authentication server to which both the client and API would talk to as shown in the figure below:
But if the token is provided by some external service, Can we use it to validate our web API. Are there any ways to implement such authentication?
You can learn more about AAD Signing Keys and handling Key Rollover using this page: Signing key rollover in Azure Active Directory
Validation of the token, once you have the signing key, can be done using existing libraries like OWIN. You can also try following instructions like this (although it seems the document isn't 100% complete yet): Manually validating a JWT access token in a web API
This library is also available, but I think OWIN is supposed to have replaced it in general.
Also check out this blog post, which has a pretty great deep dive into token validation.
I have a web service for which the user authentication is provided by web browser Single Sign-On authentication method , through which a human user is automatically logged in with his/her company email ID from a web browser.
I have written a java Jersey 2.x client (a non human consumer of web service). In client code I am using HttpAuth as
HttpAuthenticationFeature feature = HttpAuthenticationFeature.basic("ENTER_USERNAME_HERE", "PASSWORD_HERE");
But the client fails stating the HTTP status code as 302 (redirection error)
Then I used curl for the same and received the response as an HTML page stating
The document is moved here(<-- a link containing websso url to my resource).
After searching on SO I enabled the FollowsRedirection feature for my jersey client and now the error is changed to
Exception in thread "main" javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
Any pointer on how to handle this authentication problem ?
The issue was finally resolved , so I am going to answer my own question,
After all the RnD , it was clear that there isn't any sophisticated way for passing (Authenticating) the WEb SSO (Single Sign-On) from jeresy 2.x client code.
Although I found some interesting articles regarding kerberos here and here.
So , finally
I created an other URL path as
/AuthWithCert CONTEXT in server proxy configuration and added the requests coming from this path as an exclusion in webSSO login conf.
So automatically the authentication was pointed to default (HttpBasic Client Auth) without any redirection error and the client worked fine.