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.
Related
I'm providing an external-facing REST GET API service in a kubernetes pod on AWS EKS. I had configured an ALB Ingress for this service which enforces Cognito user pool authentication. Cognito is configured with Authorization code grant with the openid OAuth scope enabled.
If I invoke my REST API from the browser, I get redirected to the Cognito login page. After a sucessful authentication on the form here, I can access my REST GET API just fine. This works, but this is not what I'd like to achieve.
Instead of this, I would need to use a Bearer token, after getting successfully authenticated. So first I invoke https://cognito-idp.ap-southeast-1.amazonaws.com using Postman with the request:
"AuthParameters" : {
"USERNAME" : "<email>",
"PASSWORD" : "<mypass>",
"SECRET_HASH" : "<correctly calculated hash>"
},
"AuthFlow" : "USER_PASSWORD_AUTH",
"ClientId" : "<cognito user pool id>"
}
and I get a successful response like:
"AuthenticationResult": {
"AccessToken": "...",
"ExpiresIn": 3600,
"IdToken": "...",
"RefreshToken": "...",
"TokenType": "Bearer"
},
"ChallengeParameters": {}
}
In the last step I'm trying to invoke my REST API service passing the Authorization HTTP header with the value Bearer <AccessToken> but I still get a HTML response with the login page.
How can I configure Cognito to accept my Bearer token for this call as an authenticated identity?
Quoting AWS support on this topic: "the Bearer token can not be used instead of the session cookie because in a flow involving bearer token would lead to generating the session cookie".
So unfortunately this usecase is not possible to implemented as of today.
STANDARD BEHAVIOUR
I would aim for a standard solution, which works like this:
API returns data when it receives a valid access token, or a 401 if the token is missing, invalid or expired - the API never redirects the caller
UIs do their own redirects to the Authorization Server when there is no token yet or when a 401 is received from the API
If it helps, my OAuth Message Workflow blog post demonstrates the 3 legged behaviour between UI, API and Authorization Server.
API GATEWAY PATTERN
It is perfectly fine to use an API Gateway Design Pattern, where token validation is done via middleware before hitting your API.
However that middleware must return a 401 when tokens are rejected rather than redirecting the API client.
IMPACT OF APIs REDIRECTING THE CLIENT
This may just about work for web UIs, though user experience will be limited since the UI will have no opportunity to save the user's data or location before redirecting.
For mobile / desktop apps it is more problematic, since the UI must redirect using the system browser rather than a normal UI view - see the screenshots on my Quick Start Page.
CHOICES
Any of these solutions would be fine:
Possibly the middleware you are using can be configured differently to behave like a proper API Gateway?
Or perhaps you could look for alternative middleware that does token validation, such as an AWS Lambda custom authorizer?
Or do the OAuth work in the API's code, as in this Sample API of mine
MY PREFERENCE
Sometimes I prefer to write code to do the OAuth work, since it can provide better extensibility when dealing with custom claims. My API Authorization blog post has some further info on this.
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'm trying to make a request from my reactjs app existing on "localhost:3000" to my django living in "localhost:8000"
I was expecting some authentication token in header to passed along with the request, but it's not the case. The request seems to be stripped and the token is nowhere to be found. Unless I pass the token in the url as a parameter (which exposes the token that can be decoded. I don't like it), I can't seem to be able to get the token in any way.
so my questions:
is this CORS issue? My understanding is that CORS usually deals with javascripts only, and Django already has the middleware to deal with this.
I'm currently using a GET as method. Does using a POST help in this case? How would the reactjs script be written? Currently it's just a href attached to a NavItem
and ultimately:
How do I pass the token from reactjs to django?
We can perform the implicit grant on the front-end and then configure the Django API in Auth0 and specify its identifier in the audience parameter. This would grant you an access token which you could then use against your API. Your API would then verify the token and check the audience is correct. (This has a good overview of the process https://auth0.com/docs/api-auth/grant/implicit and then with the API https://auth0.com/docs/architecture-scenarios/spa-api)
Basically what we can do is when Auth0 authenticates the user it redirects the user to the app with an access token, and optionally an id token, in the hash fragment of the URI. We can extract that and use the token to call the API on behalf of the user.
So, after we have [created the API in Auth0][3, [defined the endpoints]3, and secured the endpoints we can call the API (by sending the access token in an Authorization header using the Bearer scheme).
If you have any Auth0 specific question please feel free to join over in community.auth0.com you may have better luck finding help/solutions.
The 403 error is telling you that the request is not being processed because something is stopping from process that request 403: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated
As you said probably because the CORS, try to follow the guide bellow of how to install Django-cors
https://github.com/mbrochh/django-graphql-apollo-react-demo#add-jwt-authentication-to-django
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
I'm trying to do authentication from app center for mobile devices but I get this error when I try to exchange code parameter for access token:
{
"error": {
"message": "Error validating verification code. Please make sure your redirect_uri is identical to the one you used in the OAuth dialog request",
"type": "OAuthException",
"code": 100
}
}
Auth token parameter is in Query String format because my app uses server-side authentication.
The url I'm calling is https://graph.facebook.com/oauth/access_token and the redirect_uri parameter I'm sending to is like the following one:
http://www.example.com?ref=app_directory&code=codefromfb&fb_source=appcenter_mobile&fb_appcenter=1
www.example.com is the value I've set in mobile site url field in app settings.
Authentication from app center for web it's ok.
I don't understand what it's wrong in redirect uri form mobile devices...
Could you help me?
I found this post referencing needing a trailing slash on the URI
redirect_uri error in oauth for facebook django app
I had the same error. I couldn't solve it but found a workaround:
I ignore the code param that is sent to my mobile web app by Facebook automatically; instead I make a request for code myself, then I exchange code for access_token using the same redirect_uri I used to request for code.
To make it easier to apply the workaround, in your app > settings > permissions, you can change Auth Token Parameter from query string to URI fragment. Then Facebook won't send you code param automatically--you will have to make a request for it--that's what is needed.
Another way to solve it is to implement client-side authentification flow using URI fragment or parse URI fragment at the client-side and send access_token to the server as a param. I didn't test this approach yet.
Redirect URLs that are working for app center authentication
desktop: http://www.example.com/?fb_source=appcenter&fb_appcenter=1
mobile: http://www.example.com/?ref=app_directory
(part fb_source=appcenter_mobile&fb_appcenter=1 should be excluded for mobile, I think that it's FB bug)
Where:
http/https - depends on request
www.example.com - you should use exactly same string as saved at application settings (https://developers.facebook.com/apps/YOUR_APPLICATION_NUMBER/summary) Domain name is case sensitive for Facebook (also bug)