CODEWITHSUNDEEP
amazon-web-servicesaws-lambda
reza
reza

Reputation: 6358

AWS API gateway authentication without using Cognito

I currently work on a system where we have a custom authentication/authorization system.

We are migrating to AWS and Web API and lambda... I want to reuse what we currently have for authe/authorization.

I am thinking of a authentication/authorization lambda that has an endpoint for login in and one for getting roles for a specific user.

The web API routes those 2 routes to authentication/authorization lambda and the rest to other lambdas.

I also need to use JWT for follow on calls to the gateway. Where does the token generation/use will have to happen in my above scenario?

Is there a better way of leveraging our custom user/roles scheme in this new AWS gateway/lambda universe?

Upvotes: 1

Views: 983

Answers (1)

Arka Mukherjee
Arka Mukherjee

Reputation: 2310

As mentioned in the comment by Reza Nasiri, a Custom/Lambda Authorizer seems to be your best option. You could write a custom validation logic in your Lambda Authorizer function, and the Lambda Authorizer could validate a JWT Token as per your requirements. You have complete code freedom when you are using a Lambda Authorizer, and you could have any kind of logic implemented, and hence utilize Tokens/Strings from your old Authentication Engine.

A sample code snippet for a Token(String) based Lambda Authorizer as per the official documentation is presented as follows: 

// A simple token-based authorizer example to demonstrate how to use an authorization token 
// to allow or deny a request. In this example, the caller named 'user' is allowed to invoke 
// a request if the client-supplied token value is 'allow'. The caller is not allowed to invoke 
// the request if the token value is 'deny'. If the token value is 'unauthorized' or an empty
// string, the authorizer function returns an HTTP 401 status code. For any other token value, 
// the authorizer returns an HTTP 500 status code. 
// Note that token values are case-sensitive.

exports.handler =  function(event, context, callback) {
    var token = event.authorizationToken;
    switch (token) {
        case 'allow':
            callback(null, generatePolicy('user', 'Allow', event.methodArn));
            break;
        case 'deny':
            callback(null, generatePolicy('user', 'Deny', event.methodArn));
            break;
        case 'unauthorized':
            callback("Unauthorized");   // Return a 401 Unauthorized response
            break;
        default:
            callback("Error: Invalid token"); // Return a 500 Invalid token response
    }
};

// Help function to generate an IAM policy
var generatePolicy = function(principalId, effect, resource) {
    var authResponse = {};

    authResponse.principalId = principalId;
    if (effect && resource) {
        var policyDocument = {};
        policyDocument.Version = '2012-10-17'; 
        policyDocument.Statement = [];
        var statementOne = {};
        statementOne.Action = 'execute-api:Invoke'; 
        statementOne.Effect = effect;
        statementOne.Resource = resource;
        policyDocument.Statement[0] = statementOne;
        authResponse.policyDocument = policyDocument;
    }

    // Optional output with custom properties of the String, Number or Boolean type.
    authResponse.context = {
        "stringKey": "stringval",
        "numberKey": 123,
        "booleanKey": true
    };
    return authResponse;
}

The Lambda Authorizer generates an IAM Policy, based on the results of the validation that takes place. Hence, you could generate custom policies as per your use-case.

Upvotes: 2

Related Questions