AUTHENTICATION FOR APPS AND SERVICES:
KEYMASTERARIEL SALOMON, LOOKOUT, INC.
SO YOU’RE BUILDING AN APP
SO YOU’RE BUILDING AN APP
WITH A BACK-END IN THE CLOUD
HOW DO YOU AUTHENTICATE REQUESTS?
AUTH(ENTICATION) VS. AUTH(ORIZATION)
• Authentication is about validating that you are who you say you are
• Verify that a credential is correct
• Authorization is about what you are allowed to do
• In general, Authorization is closely tied to your application
SIMPLE AUTHENTICATION SCHEME
• App knows some username and password
• Every time you need to do anything, include that in the request
WHY NOT?
PROBLEMS W/ SIMPLE AUTH
• The app needs to keep it’s credentials secure
• Every request embeds the credentials; can they be snooped?
• What happens as we scale up the system
• Your system is getting more complicated
• More than one service providing functionality• They all need to share
authentication• AUTHORIZATION will
vary
SCALING UP
App
Service B
Service A
• Now we scale up our back-end: apps talks to multiple services
• How does Service B verify credentials?
• Options• Ask Service A
SCALING UP
App
Service B
Service A
• Now we scale up our back-end: apps talks to multiple services
• How does Service B verify credentials?
• Options• Ask Service A
SCALING UP
App
Service B
Service A
Service B
Service B
Service B
Service B
Service B
Service B
Service B
Service Z
• Now we scale up our back-end: apps talks to multiple services
• How does Service B verify credentials?
• Options• Ask Service A• Create yet another
service, ask it..• Do some caching?
SCALING UP
App
Service B
Service A
Auth Service
A BETTER WAY
• Signed tokens verify that authentication has happened
• One service knows how to authenticate for apps, and provides tokens
• Any service can receive the tokens and verify a client without any other network traffic
• App gets a long-lasting token
• Services don’t take a network hit to handle authentication
SCALING UP WITH TOKENS
App
Service B
Service A
Auth Service
KEYMASTER TOKENS
• Signed tokens based on Java Web Token (JWT) standard [in process at IETF]
• Each token contains claims:
• sub: Subject, the device or account being identified
• iss: The token Issuer
• exp: Expiration date-time
• From the device (app) perspective, they are opaque
KEYMASTER
• To validate tokens, a service must know public keys for other services
• Keymaster service can provide this:
• Use the issuer embedded in the token to identify the key
• Ask Keymaster for a public key
• cache this for a long time
KEYMASTER BETWEEN SERVICES
• Any service can generate tokens
• Can include information in the tokens that should be signed, encrypted
Keep in touch with
@lookout
/mylookout
blog.lookout.com
http://bit.ly/scaling-for-mobile
