Similar questions have been asked here and other places, but I'm stuck...
I have a user pool set up as the authorizer for my REST API and the method, which point to a Lambda function (proxy integration). I can go through the sign-in process but I get 401 Unauthorized -- without it hitting the Lambda at all (no logs appear for the lambda function, and the API Gateway logs just show that it was an unauthorized request). I see the id_token in the URL -- but it's not sent as the Authorization header. If I take that id_token and use Postman to run the request with that in the Authorization header, it works.
I'm sure I'm missing some kind of configuration that would send those parameters in headers instead of in the URL, but I can't find it.
fwiw, I'm just serving up static HTML pages from the endpoint in question...
I've set the app client to accept either Google or the Cognito User Pool user auth. Same results.
Related
We have a scenario where we have different apps in the backend that needs to do some operation between them. Those apps are registered in the Okta console and have their own workflow. They both allow access to users that authenticate through an access token that they will get through a process the widget on the web. The two services needs to perform operations between them. For example, on one service we need information about products on another service. But it's not a "user" request, it's a service to service.
As far as my understanding goes, we still need to send a request as it would a normal user, so we need a bearer token to authenticate the request.
I cannot find in the docs a way to request an access token on the backend. I only found some libraries that can help providing a callback uri and multiple step process where you need to have a window to pop up to interact to insert your Okta login.
Is there any way to request an access token as an API call? In the backend services we won't have windows to pop up and authenticate?
We tried to use Okta-auth-js but seems to be more "front-end" oriented as most of the methods are "browser-only".
Yes, you need to create OIDC application of type "OAuth service", which will created "client credential" flow app for you. It supports calls to /token endpoint using client_id and client_secret available after the creation of the app in Okta. As a result of your call to /token directly from the backend, you will obtain an access token for machine-to-machine communication (no user context)
I have a .net core 3.1 web api authenticated by jwt in the middle ware pipline.Works fine. I converted the web api to a lambda web api by adding a aws Lambda entry class and published into aws with an API Gateway in front
All the endpoints without Authorization attribute worked fine.
All the endpoints with Authorization attribute gets 401.
All request has a jwt Authorization Bearer token header
One endpoint without Authorization attribute reponses with all the headers converted to a string.From that i can see the request's jwt is getting thru to the endpoint.
1.Why isnt the endpoint giving me 401 even tho there is a token?
2.Does AWS lambda or the API getway not pass the header direstly?
3.Do I need to configure the api geteway to send the header to the lamdbda endpoint?
4.Can Lambda authenticate by pipline like a normal web api?
Another solution was to use authorization Lambda with the API GETWAY.
If I use authorization Lambda does that mean my end point wont need the authorization attriibutes any more because it done in the getway?
JWT is generated and authenticated by Firebase.
It works I finally figured the reason. Its so awesome you can have Web api as a Lambda in aws. I can now spend less money in AWS.
I have stumbled upon a problem with Spring Security and Angular.
On my BE (Spring Boot application), there are defined OAuth2 providers, such as Google, GitHub and Facebook.
My BE works fine with this providers, since I can authenticate on the desired providers.
The problem is when I try to send the principal object to the FE (Angular 6 application).
I get undefined value when i try to subscribe the value from the rest endpoint.
I assume this is due to the Spring Servlet creating a new thread for the login request.
I am doing my login request from the Angular app.
I did watch dozens of tutorials and rad so many articles, but I just can't find the answer. If it's possible for you to share some code on how it is done, or give me a link, since for sure I am making a silly mistake and can't seem to find the answer here.
Thanks for understanding, have a good day.
:)
I am assuming that you are using the Authorization Code flow from your BE to authenticate the user that interacts with your FE Angular application (you in your example). Otherwise, you would be trying to authenticate the BE Client with the Client flow and you wouldn't need to return the "principal object" to the FE application. If my assumptions are correct... read on.
The Authorization Code flow goes as follows:
1) The user somehow selects an Authentication provider (ex: Google) and that selection is returned to some endpoint in the BE as a non-authenticated request..
2) The BE Client receives this request, preferably intercepted by a filter and, since the request is not authenticatedd, redirects the browser to the selected auth provider's authorization endpoint.
3) The user then proceed to authenticate against that provider which, upon succesfull authentication, returns a response that redirects the browser to a BE Client endpoint. That redirect holds a parameter that provides a code that the BE Client will use to get an idToken representing the user. At this point, it is important to note that the browser has not been returned any response for this redirect.
4) The BE Client then proceeds to send a regular HTTP request to the provider's token endpoint along with the received authorization code. The provider then returns the idToken an HTTP response directly to the BE Client. All this is happening while the browser is still waiting for the response to the last redirect.
5) The BE Client then process the idToken (verification, validation, user details, session etc) and only then, will finally send the response to the browser patiently waiting since the code redirect. That response may provide a header or a cookie with a sessionId or token (your choice) that the FE application will be able to read or use for the given purpose.
This flow is relatively easy to implement and requires minimal SS configuration. You must keep the BE Client auth endpoint with permitAll() otherwise, you would not be able to trigger this flow. Also, make sure that, once the FE app. has received the header/cookie, all subsequent calls shall be processed as "authenticated calls". Finally, make sure to document yourself on the perils of stateless sessions as well as cookie security and always use HTTPS.
Jake.
I'm writing an API back-end that I want to use OpenID Connect (OIDC) to secure. I've been reading the documentation but I'm still a bit confused what process applies to each and every API request. The Open ID Connect code flow appears to be:
Which I'm fine with, as a one-time process. My back-end API sees an authorization code in the HTTP headers, and sends a request to the authorization server to get the id token. Assuming this validates OK, the data requested is returned in the API response.
But assuming the same user will then be making lots of requests to this API, what happens in subsequent requests? Is there some sort of session created in this mechanism? Do I continue to receive the same authorization code? Do I have to keep sending these back channel requests to the authorization server?
Or should I even output the JWT id token as a cookie? In this way I get the self contained id token coming back in future requests, with no need of a server side session, or further round trips.
I've been reading the documentation but I'm still a bit confused what
process applies to each and every API request
It is not the API that should follow OpenID connect protocol. It's the client that should do it.
My back-end API sees an authorization code in the HTTP headers, and
sends a request to the authorization server to get the id token.
Assuming this validates OK, the data requested is returned in the API
response.
Authorization code must be used by client application and not by the API endpoint. Also, authorization code must never be exposed to other entities.
You should use id token sent with OpenID Connect to authenticate the end user from your client application. To access API, you should use access tokens.
What to do in API endpoint ?
I think this is where you struggle. Your client application should send a valid access token to get access to API endpoint. From API endpoint, you can use OAuth 2.0 introspection endpoint to validate the tokens.
RFC7662 - OAuth 2.0 Token Introspection
This specification defines a protocol that allows authorized
protected resources to query the authorization server to determine
the set of metadata for a given token that was presented to them by
an OAuth 2.0 client.
Note that, OpenID Connect is built on top of OAuth 2.0. This means you can use anything defined in OAuth 2.0, including introspection endpoint. Use this endpoint to verify the access token validity.
What if you want end user details ?
OpenID Connect defines a user info endpoint
User info endpoint
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a request to the UserInfo Endpoint using an Access Token obtained through OpenID Connect Authentication. These Claims are normally represented by a JSON object that contains a collection of name and value pairs for the Claims.
Here also, you use access tokens to get user information from this endpoint. The response will let you know the end user to which this token was issued.
Depending on your specific API requirement, you can do a token introspection or obtain user information from user info endpoint. Once that is done you may go ahead and authenticate a session. You might use both endpoints if you need all available information.
Alternatively(instead of sessions) your API can maintain an access token cache. This will remove the need to validate tokens in each an every API call. But be aware that tokens have expiration time. You must consider about token expiration if you are choosing this solution.
p.s - Client vs Resource server
In OpenID Connect and OAuth 2.0 terms, a client could be a simple web page, desktop application or could be even server hosted application.
client
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
Obtaining tokens and using them is the duty of the client application.
On the other hand, resource server contains protected resources,
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
Resource server exchange it's resources to access tokens. If we match the same scenario to basic authentication, access tokens replaces username/password sent with authentication headers.
Typically you'd secure a (pure) API with OAuth 2.0, not OpenID Connect. The Client accessing your API should obtain an OAuth 2.0 access token and in order to do that it may choose to use OpenID Connect to obtain that token. That is all independent of the API, which will only see the access token. The API (or Resource Server in OAuth 2.0 terminology) is not depicted in your diagram.
Im writing a application for outlook, front-end Angular, backend Web API.
I'm successfully getting access-token using adal in front-end, sessionStorage is:
adal.access.token.keyxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"Access-token"
adal.error:""
adal.error.description:""
adal.expiration.key:"0"
adal.expiration.keyxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"1482073764"
adal.idtoken:"access-token"
adal.login.error:""
adal.login.request:"http://localhost:8080/"
adal.nonce.idtoken:"xxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09"
adal.session.state:"86xxxxxd-xxxx-480b-xxxx-34923xxxx918"
adal.state.login:"9axxxxxx-xxxx-xxxx-xxxx-360xxxxxx94"
adal.token.keys:"xxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09|"
adal.token.renew.statusxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"Completed"
Now i'm sending access-token to backend, and i want to get messages from outlook API, but how can i do it.
Searched for outlook REST api, and tested using POSTMAN, but not working.(401 error)
Get https://outlook.office.com/api/v2.0/me/messages
Authorization: Bearer access-token
Accept: application/json
Any suggestions on how to do this?
Thanks in advance.
It looks like you are trying to complete the on-behalf-of flow.
This is where a front-end API gets an access token to a middle tier service, which subsequently gets an access token to a back-end API. Let's assume that the token from the front-end to the middle tier has user context. You are able to get a token from the middle tier, to the back-end using the same user context, by requesting a new access token using the original access token.
Here are more details on the flow: Find the section titled Delegated User Identity with OAuth 2.0 On-Behalf-Of Draft Specification
Here is a code sample integrating this flow:
https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof
Just to note, in this specific case, that the 401 error implies that you do not have the correct permissions for calling and accessing the API you want. Can you make sure you have selected the right permissions for the resource you want to access, for the client that you are accessing it with?
I hope this is what you are looking for!