JavaScript App Security: Auth and Identity on the Client

JavaScript App Security: Auth and
Identity on the Client
Jonathan LeBlanc
Director of Developer Advocacy @ Box
Email: jleblanc@box.com

What are the issues on the client?
Front-end JavaScript code should be
treated as a completely insecure
environment when making privileged API
requests
Jonathan LeBlanc • Director of Developer Advocacy @ Box • Twitter: @jcleblanc • Email: jleblanc@box.com

Agenda for Today
Browser and Data: Working with browser security
and identifying sensitive data.
API Communication Hurdles: Services and standards for
handling auth and identity.
Improving Token Security: How to work with tokens
linked to highly secure information.

1 What data should be secured?
Application Keys (app identity)
Public / private keys, application access keys, or
any other app authentication keys.
Access Tokens (app access)
Generated access tokens, pre-authorized access
tokens, or any other string that grants privileged
access to resources.
Sensitive Information
Any sensitive non-anonymized, unencrypted,
information that can be attributed back to a user.

The browser security model restricts API
requests to the same domain,
subdomain, and port as the originating
request.
1 What problem do we need to solve?

1 The technology we’re looking at
CORS (Cross Origin Resource Sharing)
Allows a web app running at one
origin to access resources from
another origin by using additional
HTTP headers.
https://www.w3.org/TR/cors/

OPTIONS /cors HTTP/1.1
Origin: http://mysite.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
Host: api.service.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
Example CORS Preflight Request

Access-Control-Allow-Origin: http://mysite.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization,
Content-Type
Content-Type: text/html; charset=utf-8
Example CORS Preflight Response

Part 2: API Communication Hurdles

2 Authentication versus Authorization
Authentication
Services, specifications, or
processes that are used to
identify a user or an
application.
Authorization
Processes that are used to
grant an application permission
to make requests on behalf of
the user or application.

When making API requests, most
services require that you are authorized
to make those requests, either as the
application or the user.

CORS
As previously discussed, this
will allow us to make HTTP
requests to the required API
service at another origin.
OAuth 2
OAuth 2 is the open
authorization system that may
be used to make authorized
requests to the API service.

2 How the standard OAuth 2 flow works
ClientApplication
OAuthService/ResourceOwner
1. Client app redirects user to log in / authorization
2. OAuth Service sends authorization grant
3. Client POST request to fetch access token
4. OAuth service validates and sends access token
5. Client makes requests for privileged resources

2 How the OAuth 2 implicit grant flow works
ClientApplication
2. OAuth Service validates client app and responds
with access token in query string

https://www.myapp.com/callback
#access_token=T9cE5asGnuyYCCqIZFoWjFHvNbvVqHjl
&refresh_token=J7rxTiWdOHbUnsUfGMinKBDLZWP9BgR
&expires_in=7200
&state=mystate
Example of a returned token is the OAuth 2 implicit grant flow

The standard 3-legged auth process
means that you have to log in to the API
service. How can I use my existing
identity system to use the service behind
the scenes?

OAuth 2
OAuth 2 is the open
authorization system that may
be used to make authenticated
requests to the API service.
JWT
JSON Web Tokens provides a
mechanism for including an
existing identify system to
bypass the OAuth 3rd leg.

2 Which part of the flow does JWT target?
ClientApplication
2. OAuth Service validates client app and responds
with access token in querystring

2 What are the components of a JWT request?
X (Header): Token type and hashing algorithm
Y (Payload): User / verification content
Z (Signature): Header, payload, and secret
XXXXXXXX.YYYYYYYY.ZZZZZZZZ

2 The components of a JWT header
alg: The hashing algorithm to be used (RSA / HMAC).
typ: The token type, always JWT.

2 The components of a JWT payload
iss (issuer): The person that issued the token.
sub (subject) : The subject of the token.
aud (audience) : Audience the token is intended for.
exp (expiration time) : Expiration time of the token.
nbf (not before) : Starting time token is available.
iat (issued at) : When the token was issued.
jti (JWT ID) : Unique identifier for the token.

2 The components of a JWT Signature
Encoded Data: Base64 encoded header + payload.
Secret: A private key.

const header = { alg: HMAC', typ: 'JWT' };
const payload = {
sub: '4355676', exp: '1481160294', jti: '841112’
};
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Sample JWT Request Segments

2 Securing JWT / OAuth 2 Communication
Web App
Doesn’t hold
persistent token,
simply assumes a
token is available
Identity Provider
Service like Auth0 to
manage secure
identity / token
procurement from
the API service
Serverless Function
Serverless API
gateway function
with code to
procure tokens (e.g.
Webtask, AWS
Lambda)
API Service
Service that
provides endpoints
for data which the
web app would like
to consume

Part 3: Improving Token Security

When using an access token within
frontend code, you are exposing a
potentially long lived keys with extensive
data access permissions.

Token Downscoping
The ability to programmatically
generate a highly restricted child
token with the intent of
minimizing information exposure
in insecure code / environments.

3 Token downscoping process
Fully Scoped Token
Standard OAuth 2 token
that is fully scoped with
the application and user
permissions
Downscoped Token
New child token that is
tightly restricted for read
/ write access and
permissions.
Client-side Code
Downscoped token is
deployed to client-side
code, mobile, or UI to
make HTTP requests.

3
Tightly scoped for single file: A token should only be scoped for the item
needed for processing, such as a file.
Short lived: Downscoped tokens should only live for their natural useful time
(e.g. 1 hour) and should not be refreshable.
Revocable: Downscoped tokens may be revoked before natural expiration
through the API.
Split read / write functions: To further scope token exposure, separate read /
write tokens can be issued.
Least privilege principle for downscoped tokens

3 Downscoped Token Components
New Scopes
• Preview item
• Download item
• Share item
New Access Rights
• Read access to file id
1234567
• Token revokes in 1hr
Fully Scoped, Long Lived Token
• Read / write all files / folders
• Manage all users
• Create webhooks
• Manage enterprise settings

client.exchangeToken(“item_preview, item_share, item_download”)
.then((tokenInfo) => {
// token available in tokenInfo.accessToken
}).catch((err) => {
console.error(err);
});
Downscoping a Token Example

Topic Recap
Browser and Data: How do we communicate from JS
and what data should we protect.
API Communication Hurdles: Tech to handle
authentication / authorization / key management.
Improving Token Security: Taking long lived tokens from
the API service and scoping down based on least
privilege principle.

Thank You
https://speakerdeck.com/jcleblanc
Jonathan LeBlanc
Director of Developer Advocacy @ Box
Email: jleblanc@box.com

JavaScript App Security: Auth and Identity on the Client

More Related Content

What's hot

Similar to JavaScript App Security: Auth and Identity on the Client

More from Jonathan LeBlanc

Recently uploaded

JavaScript App Security: Auth and Identity on the Client