I am trying to create a simple service using AWS API gateway and Lambda.
I want to manage small amount of user/password pairs such that they can login in to get an access token to proceed with future API calls.
I am not sure if I have chosen the right tools for this, but I am wondering if there is any existing package or model that I can use to implement this functionality?
A document titled "Amazon API Gateway + AWS Lambda + OAuth" describes what you need to do to protect a Web API implemented using Amazon API Gateway + AWS Lambda with an OAuth 2.0 access token. The introspection API (= an API to get information about an access token) used in the document is Authlete's one, but you can replace it with another different one you like. For example, if you use an authorization server implementation that supports RFC 7662 (OAuth 2.0 Token Introspection), you can use the introspection API defined in the specification.
Updated on 2016-Apr-6
On Feb 11, 2016, a blog entry of AWS Compute Blog, "Introducing custom authorizers in Amazon API Gateway", announced that Custom Authorizer had been introduced into Amazon API Gateway. Thanks to this mechanism, an API built on Amazon API Gateway can delegate validation of a Bearer token (such as an OAuth or SAML token) presented by a client application to an external authorizer.
How to protect APIs built on Amazon API Gateway by OAuth access tokens utilizing the new mechanism, Custom Authorier, is described in "Amazon APi Gateway Custom Authorizer + OAuth".
Related
I would like to implement an SPA which bounces the user to a login page, if not already logged in. It would then able to make a call to an API (not necessarily an API Gateway) hosted within an AWS VPC.
As I currently understand it, this would involve a front-end framework library authenticating the user via OAuth 2.0. It would then need to retrieve a token (allowed because of the auth validation) to call an API Gateway which provides access to the API hosted within the VPC.
Given this concept, is this architecture possible without the use of a Lambda?
If you are willing to use API Gateway in front of your API:
Yes, this architecture is possible without using a Lambda. API Gateway has integration with AWS Cognito User Pools for authorizing requests. You can find the AWS docs on how to set this up.
If you don't have an AWS API gateway in front of your API:
In this case you will have to implement one of the authentication and authorization flows provided by OAuth 2.0 standard. In this case, whether you would want to use a Lambda or not, is up to you and your back-end architecture.
I am watching an AWS reInvent video: https://www.youtube.com/watch?v=kmVUbngCyOw&feature=emb_logo&ab_channel=AmazonWebServices where it suggests to use Cognito pool per tenant.
This is what the authentication looks like and introduces an Auth manager to Auth against Cognito and gets back a JWT token based on OpenIdConnect.
I was reading another blog post here: https://medium.com/#tarekbecker/serverless-enterprise-grade-multi-tenancy-using-aws-76ff5f4d0a23
and It suggested using a Custom Authorizer attached to the API gateway.
Am I right in understanding that we should basically be authenticating in 2 places ->
From the web app using Auth Service
At API gateway using custom authorizer
Generally, people use the AWS SDK to authenticate the user from Cognito and it handles the whole authentication logic. AWS-SDK is available in almost all popular languages.
As API gateway is the frontline service or the publically exposed service through which you can access the microservices hosted using Lambda. Also, ApiGateway interacts as an intermediary/broker service between any client application including Web and Lambda microservices.
Custom Authorizer is used for implementing the custom authorization logic at the API Gateway service i.e. if a user role doesn't have any access to certain Apis it'd just give an error to the user trying to access those resources.
For example how we used Custom Authorizer in the past. We had users with 2 role types
Admin
User
We had to restrict the access of the admin Apis. So we added all this logic to authorize access to the Apis based on the information we get in the bearer token.
https://aws.amazon.com/blogs/compute/introducing-custom-authorizers-in-amazon-api-gateway/
Seems like all the information on using Cognito to protect APIs requires using AWS API Gateway, but this gateway costs extra and there are many other API Gateway products available.
You could present the id or access token returned by Cognito to whatever API system you are using and validate the tokens yourself.
See https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html
I am entirely newbie in Amazon Web services. Currently i am developed a REST API service using Laravel's micro frameworks called Lumen. I am using passport for token based authentication and all that working fine. I need a proxy server to hide my actual endpoints and do some other functionality so i am planning to use AWS API Proxy Gateway and host the API endpoints in EC2 instance.
i went through Build an API with HTTP Proxy Integration from Aws documentation. but there is nothing about using a custom authentication using Oauth.
My Doubts are
How to use Passport authentication when using AWS API Gateway
Is there any good method to hide my REST Endpoint from customer and need a way to change the proxy end point from time to time.
I don't know Laravel ecosystem, but:
if passport expose something like an OpenId Connect you could use Cognito Federated Identities for, precisely, federate your identity, and associate the authorized identities with a given IAM role and unauthorized with another role;
you can use an Api Gateway Custom Authorizer to perform fully customizable auth;
Try expanding your question so we could add more details...
Yes, like what BAD_SEED said, you can use API Gateway Lambda authorizer (formerly known as the custom authorizer) to do any logic to verify the token, since it's just a javascript package.
So, one option is like what auth0 does in (https://auth0.com/docs/integrations/aws-api-gateway/custom-authorizers/part-3) and (https://github.com/auth0-samples/jwt-rsa-aws-custom-authorizer). Their sample authorizer does followings:
It confirms that an OAuth2 bearer token has been passed via the Authorization header.
It confirms that the token is a JWT that has been signed using the RS256 algorithm with a specific public key
It obtains the public key by inspecting the configuration returned by a configured JWKS endpoint
It also ensures that the JWT has the required Issuer (iss claim) and Audience (aud claim)
But unfortunately, Passport does not support JWKS endpoint (which exposes public key for the token signature). So you may have to expose it by yourself.
Another option is much easier, you just make a token verification endpoint in your application, something like /users/me, and protect it with auth middleware. Then in your Lambda authorizer, call it with the token in the request to your other micro service endpoints. By this way, all token verification stuff is left to Passport, and the authorizer just executes policy based on the result of the verification.
Not very sure about what you want to reach, but API Gateway is just a proxy, so you can certainly change backend side endpoints for its frontend one, which is better not changing so often.
I have an existing Web API that I migrated to AWS using API Gateway and Lambda functions. However, I'm wondering how I can make use of AWS API Gateway's custom authorizer feature. My existing authorization framework is OAuth and I used ASP.Net Identity for user management. I generate bearer tokens and used the 'Authorized' attribute in my API Controllers for security. How can I do the same in AWS API gateway since I cannot change my framework cause I already have existing users. Thank you.
If you haven't already, check out the docs for custom authorizers: http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html
You should be able to write the Lambda function to replicate the authorization logic used in your existing service. Then think about how you want to model permissions in terms of an IAM policy (which is the output of the authorizer). If you want simple allow|deny then you can return an IAM policy from the authorizer that says Allow * or Deny *. Or you can add fine grained permissions if you want.