I am playing around with Amazon Gateway API and am struggling to get my head around security.
Obviosuly the API I create cannot be accessed by anyone and needs to be secured. Amazon suggest using API keys or IAM roles. I have a few questions:
How can i authenticate my client requests so that my app and only my app can make use of the API?
How does AWS determine a role for an incoming request?
If I choose API key approach, how does it work?
Thanks!
How can i authenticate my client requests so that my app and only my app can make use of the API?
If your backend is a Lambda function, you can grant permission to API Gateway to access it.
If your backend is a HTTP backend, you will have to find out the authenticate strategy at your HTTP backend side.
How does AWS determine a role for an incoming request?
If your API is required IAM auth, the incoming request has been signed with AWS sigV4 algorithm. AWS is able to determine the permission of the credential is used to sign the request.
If I choose API key approach, how does it work?
All the incoming requests have to contain the API key in the header. If the key is allowed to access the API, the request will be processed, otherwise it will return 403.
Related
I'm trying to verify Firebase App Check tokens on my custom backend. Everything is fine so far, but there's one thing I'm not sure about: My backend is hosted on a private network therefore I need to know if grabbing key sets from https://firebaseappcheck.googleapis.com/v1/jwks is the only necessary outgoing HTTP request involved in the verification process.
The answer is "Yes" according to https://github.com/firebase/firebase-admin-node/issues/2014#issuecomment-1353472578
Obtaining the Firebase App Check public JSON Web Key Set is the only outgoing request for the app check verify token API. The SDK might make other http calls during the initialization based on your environment (obtaining the service account or credentials etc.) or if you use other APIs in combination with the App check token verification.
The rest of the JWT verification happens all offline. We also cache the public keys (JWKS) for up to 6 hours, so if your environment doesn't lose its state then the outgoing request to fetch the keys should not happen (if the keys are cached) every time you call the API.
So, I have 3 microservices and only 1 of them is used for Authentication - it uses ASP.NET Identity.
I am issuing a token every time successful login occurs, which contains claims such as Id, Username, Balance (money), Roles.
When this JWT is created how can I pass it to other APIs? Is it necessary to use API Gateway or not? Is it bad practice to store it in local storage?
If it is not necessary, can I store this JWT as Cookie and pass it to my other APIs?
And if so -> how can I create some kind of session in my other APIs, depending on that cookie?
I am very confused on 2 main topics - how other APIs will know about this token and how in each API I can create authenticated/ authorized session, because most of the tutorials use Postman and on each request they pass this auth/ bearer token. But this is not applicable in real world situations, at all.
Instead of creating JWT auth in every API, First implement API
gateway and intergrate JWT stuff in that API Gate way.
API gateway will authenticate all api calls and will send requests
according their endpoints.
In my real scenario we are Used Ocelot API gate way and it is
open source.
I have an web application made using servlet and I have an seperate API for the web application. I want to secure the API with OAuth so that when we use OAuth, a client certificate is sent instead of credentials to the authorization server for verification and after verification the access should be allowed to the API. Is there any ways to implement this authentication. If possible what are the steps should I do to achieve this?
Client certificate credentials can be used for confidential clients, in either the code flow or the client credentials flow. This type of solution is often used in financial grade setups, where high worth data is involved.
Access tokens issued then contain a cnf claim, so that every API call is bound to the strong credential used at the time of authentication. See the RFC8705 standard for further details.
For a worked end-to-end example that you can run locally, and which covers both the
backend and client behaviours, see this Curity code example. Not all authorization servers support these flows, so check for your provider.
I've been reading through a bunch of documentation for using OAuth with Azure AD, but am still completely confused about how to properly implement things for my situation. Hopefully someone can steer me in the right direction.
I have created an ASP.NET Web API application that uses the EWS Managed API to access Exchange on behalf of different users. My application exposes endpoints such as /Mailbox/Messages and /Appointments with the intent that some front end web application will eventually use them to retrieve a user's emails and appointments. Currently the endpoints are working using basic http authentication, but I'd like to update them to use OAuth. The application has been registered in my Azure AD instance and I've configured it to require the "Access mailboxes as the signed-in user via Exchange Web Services" API permission.
Since the front end hasn't been implemented yet, I've been trying to test by manually calling the authentication endpoint. This prompts me to log in and provide consent. If I consent, I'm redirected to the callback URL that I provided when I registered the app with the authorization code contained in the query parameters. I'm still not quite sure how I'm supposed to be using this callback, but for the sake of testing I currently have the callback redeem the authorization code for an access token. This is done by calling the AcquireTokenByAuthorizationCode method on an instance of the AuthenticationContext class and providing my application's id and secret. Again, just for the sake of testing I return the access token to the browser. I can then call my aforementioned endpoints (after some modifications) with this access token and get the emails for the user. I'm guessing much of this is not the correct way to be doing things.
Some of my points of confusion:
What should the callback that I registered in Azure AD actually be doing when it gets the authorization code? Is this intended for a different type of application? Perhaps one that isn't just playing the role of a middle man.
I'm trying to make my application somewhat RESTful, so I don't want to have to maintain the access tokens on my end between requests. As such, does it make sense for my endpoints to expect that the access token be provided in the authentication header for each request? If so, does that mean the front end application should be responsible acquiring the access token and passing it to me?
Being completely new to OAuth and Azure, I'm not sure if any other details are pertinent, but I can provide more information as needed.
What you are implementing is this scenario: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#daemon-or-server-application-to-web-api
Here's how it works:
Your client app redirects the user to sign in at the authorization endpoint
Your client app gets back an authorization code (if using the auth code grant flow, there are others)
The client app exchanges the code for an access token for your API app
It will need to provide its client id and secret along with the code and the API's resource URI to get it
The client app calls to your API app, passing the access token in the Authorization header
Your API app then validates the access token, and requests for another access token from Azure AD for the Exchange API
It will pass the access token sent by the client app, along with its client id and secret and the Exchange API's resource URI to Azure AD
Your API app receives an access token so you can call to the Exchange API as the user
And to answer your two questions:
Authorization code flow is not used with APIs, only with apps that have a user signing in, thus the redirect URL is basically never used
Your API can and must expect and authenticate the access token for it to be in every request. But the access token it uses to call the Exchange API can and should be cached on the API's side. This is provided out-of-the-box with ADAL, though the tokens are only in memory.
I have an admin-console for an existing service that I want to provide access to by adding login, using our company's OAuth 2.0 service. I want to use Apigee here, so that the web-app with the admin-console does not have to implement the login-logic.
My idea was to use AuthorizationCode flow and let Apigee manage the tokens and I looked into https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, but I really can't see how our existing OAuth service fits in.
Is there a sample like that? Perhaps using Google's or Facebook's OAuth service to authenticate the user?
First, Apigee needs to be a proxy into the admin-console. This means that all traffic to the admin-console has to go through Apigee. Otherwise, you won't be able to enforce authentication.
Second, there are a couple different options for integrating with the external oauth 2.0 service. Apigee has the ability to store an external access token and use it as its own, or Apigee can generate a token and store the external access token as a custom attribute.
High level thoughts on how the Apigee proxy could look like:
ProxyEndpoint - endpoint exposed to clients connecting to admin console
TargetEndpoint (not shown in that oauth login-app example) - endpoint for the actual admin console
The flows that execute in the Apigee proxy before sending the request to admin-console will need to implement logic that checks an authentication token. If it's valid, let the request pass onto the TargetEndpoint (admin-console). If the request isn't valid, step through logic that goes calls the external oauth 2.0 server's auth code flow. This will require the following:
Apigee needs to be registered with external oauth 2.0 server.
Logic needs to be built in this proxy to support the redirection based flow of authorization code grant_type (obtaining auth code, receiving the auth code, obtaining token --> all while being redirection based and transparent to user).
In addition to #2, Apigee will need to store the external token as custom attribute and expose the apigee token, or store the external token for verification purposes later on. http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-20 (see Delegating token management). After the token is stored, you'd need to respond with another 302 redirect to the initial uri + token so the request can pass through to admin-console as an authenticated request.
#2 isn't exactly straight-forward and there won't be an example proxy that shows this implementation. If the oauth 2.0 service supported a password grant, it may simplify the implementation, but allows the credentials to pass through apigee and not directly with the authorization server.