Poseidon Customer Auth0 Authorisation server

Challenge Overview

In this challenge we would like to validate the OAuth flow with our backend.

 

Project Overview

The project objective is to build an SDK for the Loyalty Payment Card (LPC) for our client. This SDK will be used by LPC’s clients to build the LPC mobile app.

 

So, the SDK will provide all required functionalities, from authentication to payment processing, reward management, etc. 

 

Framework

1. AWS

2. OAuth

3. Node JS

4. Typescript 

5. Nginx ingress controller to EKS

6. DynamoDB (local) / Postgres for any datastore.

Individual Requirement

We have developed a backend API, which exposes REST APIs. We have a Developer Portal that can be used to register the Developer (using a Developer API Key).  Since this will be multi-tenanted solution and there will be multiple Enterprises using our API/SDK we also register the Developers organization (using an Enterprise API Key) in the Developer Portal.  Assume this is all stored in an AWS Cognito User Pool (but will be changed to AWS Secret Manager in future).

 

The Client Application will use our SDK, which is a consumer of our backend REST APIs, and this Client Application will have their own authentication mechanism for their end-users, i.e. they can have username/password or use any third party authentication services (e.g. google auth0, ping identity, okta, login with facebook, etc).   It is assumed for the Client Application to use our application they must be authenticated with OAuth2/OpenID Connect.  

 

Now, in this challenge we are seeking guidance on how we can identify users in this situation so that they are authenticated and authorized by the Ingress to access any service within the AWS EKS cluster.  You are welcome to look at alternatives means of achieving this but have assumed that this can be implemented using the NGINX Ingress Controller.

 

What can be assumed to be in place:

1. Developer Portal will be deployed on AWS, and use AWS Cognito for Developer Authentication.

2. It is assumed the Client has already authenticated with their own OAuth/OIC authorization server.

3. There are iOS and Android SDKs which consumes the backend API.

4. The SDK passes the OAuth token, ClientID and Enterprise API Key.

What needs to be developed:

1. A custom authentication component that will validate that the supplied Enterprise API Key has been registered earlier.
2. The custom authentication component should also check that it’s a valid OAuth token.
3. A custom authorization component that will check what resources (custom permissions) that the user (using the Client ID, rather than OAuth tokens e-mail id) are allowed for.
4. Both the custom authentication and authorization component will need to make use of a lookup service (e.g. DynamoDB, or Key-value Store, etc.) that needs to be developed.
5. A NGINX ingress Controller is suggested to access the Kubernetes cluster where the REST API is deployed.
6. Both the authentication and authorization components will require handling at the NGINX Ingress Controller (single or chained) that needs to be developed.
7. Optional is to look into caching for any of the lookups.

Our Solution

1. Solution 1

We are considering an approach as shown below

 

Figure 1

 

The green blocks are not in our control while blue blocks are our system. 

The ingress controller should authenticate the Customer through the API Key. 

 

And the second chained ingress controller should allow the End-User to go through an OAuth flow on the Customer App, and have the authorization grant token shared with our APIs

 

Refer the below auth flows - https://auth0.com/docs/flows/concepts/auth-code-pkce

 

 

Figure 2

 

The “User” above, is the End-User, which arrives through the mobile app (Client’s app who implements Poseidon SDK). And Auth0 flow is merely an example, as it will be using the Client’s authentication mechanism.  You can use a test account from Auth0 of with any other SaaS providers auth0 mechanism.

 

End-User will use the Client’s mobile App that implements the SDK, login to the client’s own authentication server (example OAuth). Gets OAuth authorization grant token, and this is sent, along with the Client’s Enterprise API Key and ClientID, in any request to the REST APIs.

 

Then, we need to authenticate that the Enterprise API Key exists – as it should have been generated in our Developer Portal – and we want this validation to be done on the EKS ingress controller (1st part of the challenge) to avoid doing so on each EKS service.

 

Subsequently, we will validate the OAuth authorization grant; with the external APIs we need access to. Again we’d like this to be implemented on the EKS ingress controller (2nd part of the challenge) to avoid doing so on each EKS service.

 

The next step, since we know the Enterprise API Key is valid and the OAuth token is valid, we need to extract the Role Permissions, and the information from the token about the End-User to provide to the EKS service. This could be in either changing the request or appending headers. (3nd part of the challenge)

 

This last step forwards the request to the underlying EKS service/resource, as long as the user has permissions to access it (Or the permissions can be validated at the resource level).  (4th part of the challenge). Optional is to look into caching for any of the lookups.

What we are looking out of this POC?

1. Validate our authentication and authorization flow process and suggest improvements

2. Submit POC codebase and detailed documentation

If there is anything let us discuss in the forum.

Final Submission Guidelines

Please submit the zip file containing the following:

1. POC codebase

2. Supporting detail documentations