Follow the steps listed in this README to follow along the demos showcased in the AWS Okta Howdy Partner Event.
Get Started with Okta
Secure a Single Page App with Okta
Secure the Resource Server
- Local Express Server
- AWS API Gateway v2
- AWS API Gateway v1 + Custom Lambda Authorizers
- AWS Application Load Balancer
Secure a Mobile App using Okta
What's coming next
Follow the instructions for installing Okta CLI here: https://github.com/oktadeveloper/okta-cli#installation
Run okta register to sign up for a new account. You will be prompted for the following information:
- First Name
- Last Name
- E-mail Address
- Company Name
Once you provide all the information, the Okta CLI will create a new Okta Developer Organization.
Check your inbox for an email from Okta noreply@okta.com with the Subject 'One-time verification code'
Copy the verification code and paste in the Okta CLI.
Once verified, you will get a link to set your password.
Copy and paste the password link in a browser and click on 'Reset Password'.
Your Okta Organization setup is now complete!
This section will help you setup a sample Single Page App with the following capabilities:
- Login and Registration
- Token Scopes and Claims
- Access Token Validation
- Logout
This SPA sample is built with VueJS. You can always use your own SPA Framework like Angular or React. Please see <developer.okta.com> to locate samples for your specific technology stack of choice.
In this sample, Okta is the OIDC authorization and token server. The SPA is the OIDC client.
Clone the [https://github.com/maneeshsahu/aws-howdy-partner] github repo:
git clone https://github.com/maneeshsahu/aws-howdy-partner
cd aws-howdy-partner
The Okta CLI allows you to very conveniently setup and configure the OIDC application.
okta start
After this completes, the .okta.env file is populated with the ISSUER and CLIENT_ID environment variables.
You will need to install npm in order to install the dependencies and run the vue samples.
cd spa
npm install
npm start
This will run the vue application locally.
In your browser, navigate to http://localhost:8080
You should see this landing page.
Click Login to continue.
Enter an account credentials. You can use the email and password that you used while creating the Okta organization.
Click Sign In.
After a successful authentication, you should see a logged in page as below:
Resource Server is the OAuth 2.0 term for an API Server. The resource server handles the authenticated requests from applications such as the Single Page App we just built.
We will look at multiple options for building the resource server, starting from an application server to modern serverless technologies.
Express is a minimalist, web framework for Node.js. Its great because it can be deployed and run wherever there is a node runtime. In this section, we will be running the resource server locally on port 8000. You can also host the server in AWS in EC2 images or better using Elastic Beanstalk.
From the aws-howdy-partner root directory, run the following commands:
cd resource-server
npm install
npm start
If all goes well, you should see this in your Terminal's standard output:
> @okta/samples-nodejs-express-4@3.1.0 start /Users/maneeshsahu/aws/aws-howdy-partner/resource-server
> node server.js
Resource Server Ready on port 8000
The resource server has one API GET /api/messages that is protected using a JWT authorizer. i.e., it checks the bearer token passed in the Authorization header for the following:
- Valid JWT and Signature
- Valid Issuer
- Valid Audience
So if you hit the endpoint directly using cURL, you will get this Unauthorized error response:
> curl http://localhost:8000/api/messages
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Unauthorized</pre>
</body>
</html>
However, if you access the resource server through the Single Page App - http://localhost:8080/messages
You will now see a list of messages:
instead of the error that you may have seen earlier when the resource server was not running.
If you open the Developer/Javascript Console of the browser and inspect the XHR calls. You will see a call to messages. You can inspect the request and response:
Resources servers hosted in application servers are good. Serverless is another method.
We are now going to host the same messages API in AWS using HTTP APis for AWS API Gateway.
We will use Serverless to setup the service in AWS.
See installation instructions here for your operating system: https://www.serverless.com/framework/docs/getting-started/
# e.g. Mac OS X via npm:
$ npm install -g serverless
AWS CLI will be used by serverless to deploy to AWS
Follow the instructions in the links below to install and configure the aws CLI:
- Install AWS CLI: https://docs.idp.rocks/setup/#install-aws-cli
- Enable Programmatic Access in your AWS Account: https://docs.idp.rocks/setup/#enable-programmatic-access-to-aws
- Create Named Profile in AWS CLI: https://docs.idp.rocks/setup/#create-named-profile-in-aws-cli
Deploy the serverless function to your AWS account
cd aws-serverless-api-gateway-v2
npm install
sls deploy -v
At the end of a successful deployment, you will see the endpoint for the messages service.
endpoints:
GET - https://8hny7YYYYYY.execute-api.us-east-1.amazonaws.com/api/messages
functions:
getMessages: messages-okta-service-dev-getMessages
layers:
None
Stack Outputs
GetMessagesLambdaFunctionQualifiedArn: arn:aws:lambda:us-east-1:661XXXXXX:function:messages-okta-service-dev-getMessages:2
ServerlessDeploymentBucketName: messages-okta-service-de-serverlessdeploymentbuck-f6je8qe5pu57
HttpApiUrl: https://8hny7YYYYYY.execute-api.us-east-1.amazonaws.com
Serverless: Removing old service artifacts from S3...
You can use the endpoint, https://8hny7YYYYYY.execute-api.us-east-1.amazonaws.com/api/messages as shown above (will be different for your deployment), in the Single Page app by updating the resourceServer.messagesUrl property in spa/src/config.js from http://localhost:8000/api/messages.
After you restart the SPA, and go back to http://localhost:8080/messages, you will see a new message at the bottom.
If you inspect the XHR requests in the Developer/Javascript console, you will also see the updated endpoint for the messages service.
The Default JWT Authorizer that ships with API Gateway v2 is good, but if you need more authorization policies beyond just basing them on scopes, you will have to utilize the API Gateway v1 with custom lambda authorizers.
Custom Lambda Authorizers allow you to make your policy decisions and create a policy document specifying which resources/endpoints that the JWT has access to.
Installation is similar to as in API Gateway v2.
cd aws-serverless-api-lambda-authorizer
npm install
sls deploy -v
You will find the endpoint after the deployment
endpoints:
GET - https://l1huvZZZZZZ.execute-api.us-east-1.amazonaws.com/dev/api/messages
functions:
oktaAuth: messages-okta-service-claims-dev-oktaAuth
getMessages: messages-okta-service-claims-dev-getMessages
layers:
None
Stack Outputs
OktaAuthLambdaFunctionQualifiedArn: arn:aws:lambda:us-east-1:661XXXXXX:function:messages-okta-service-claims-dev-oktaAuth:6
GetMessagesLambdaFunctionQualifiedArn: arn:aws:lambda:us-east-1:661XXXXXX:function:messages-okta-service-claims-dev-getMessages:6
ServiceEndpoint: https://l1huvZZZZZZ.execute-api.us-east-1.amazonaws.com/dev
ServerlessDeploymentBucketName: messages-okta-service-cl-serverlessdeploymentbuck-cxerojosuiis
Serverless: Removing old service artifacts from S3...
You can use the endpoint, https://l1huvZZZZZZ.execute-api.us-east-1.amazonaws.com/api/messages as shown above (will be different for your deployment), in the Single Page app by updating the resourceServer.messagesUrl property in spa/src/config.js from http://localhost:8000/api/messages.
After you restart the SPA, and go back to http://localhost:8080/messages, you will see a new message at the bottom.
Congrats! You have successfully created a SPA powered by Okta and AWS.
Follow the README in this repo - https://github.com/maneeshsahu/OktaMobile to build a native mobile app.