We know and love our authentication standards for the web, yet on mobile we often still resort to usernames & passwords in our apps. This presentation explores OpenID Connect (OIDC) and OAuth 2.0 in the context of mobile apps to see how they decouple authentication logic from your app and promote simpler and more flexible patterns for user authentication and API authorization. This presentation was first given in the London Mobile Security Meetup https://www.meetup.com/London-Mobile-Developer-Security/

1. Mobile Authentication
Onboarding, best practices & anti-patterns
Pieter Ennes, co-founder Authentiq

2. authentiq.com
Who am I
• Pieter Ennes (@skion)
Co-founder Authentiq
• Authentication, identity, web
performance, web standards, not
the Higgs particle
2

3. authentiq.com
Authentiq
• Passwordless authentication via
OpenID Connect
• Trivial to integrate, privacy-
focused, configurable security
www.authentiq.com/developers
3

4. authentiq.com
Abstract
• We know and love our authentication standards for the web
• Yet many apps still resort to usernames & passwords on mobile 😱
• We explore OIDC and OAuth 2.0 in the context of mobile apps
• And learn how they promote simpler and more flexible patterns for
user authentication and API authorization
• So we can build user friendly, secure and future-proof native apps
4

9. authentiq.com
Anonymity goes a long way
• Social sharing
• Saving favourites or “likes”, search
history, shopping baskets
• Personalisation, managing user
preferences
• Backup / restores
9

10. authentiq.com
Avoid passwords
• Passwords have horrible UX on
mobile
• Passwords are reused, contain
little entropy, vulnerable to offline
attacks, …
• Passwords facilitate account
sharing
10

11. authentiq.com
Personal data is toxic
• Requesting deteriorates user
experience
• Retaining is risky business (e.g.
“right to forget”)
11

12. authentiq.com12
A happy user does not need to register.

13. authentiq.com13
Entering it twice does not make the user happier.
A happy user does not need a password.

14. authentiq.com14
GET /userinfo
A clever developer avoids sensitive information.

15. authentiq.com15
A clever developer uses web standards.

16. authentiq.com
OpenID Connect & OAuth 2.0
16
For authentication and authorization.

17. authentiq.com
These standards help us with…
• Authenticating a user (OIDC)
• Obtaining profile details from a user (OIDC)
• Issuing API tokens for backend (resource) servers (OAuth 2.0)
• Implementing passwordless and multi-factor authentication
(OATH/TOTP, FIDO U2F/UAF)
• Managing account life cycles / account recovery
17

18. authentiq.com
OAuth 2.0
• Web authorisation framework to provide
limited access to web resources by 3rd party
clients
• Key Players
• Authorization Server (your internal or
external Identity Provider (IdP))
• Client (your website or app)
• Resource Owner (the user)
• Resource Server (the API to access)
18

19. authentiq.com
OpenID Connect (OIDC)
• An authentication layer on top of
OAuth 2.0
• Defines an ID Token, a signed JWT
with a consistent sub claim
• Standardises GET /userinfo
19

20. authentiq.com
ID Token
{
"iss": "https://server.example.com",
"sub": "24400320",
"aud": [“s6BhdRkqt3”, “https://my-api.server/"],
“exp": 1311281970,
"nonce": "n-0S6_WzA2Mj",
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
20

21. authentiq.com
Choosing an Authorization Server
21
Internal
Off-the-shelve
DEVELOPMENT COST: MEDIUM
SECURITY RISK: MEDIUM
LEVEL OF CONTROL: MEDIUM
LEVEL OF PRIVACY: HIGH
LEVEL OF SOVEREIGNTY: VARIABLE
Self-built
DEVELOPMENT COST: HIGH
SECURITY RISK: HIGH
LEVEL OF CONTROL: HIGH
LEVEL OF PRIVACY: HIGH
LEVEL OF SOVEREIGNTY: VARIABLE
External
Social
DEVELOPMENT COST: LOW
SECURITY RISK: LOW
LEVEL OF CONTROL: LOW
LEVEL OF PRIVACY: LOW
LEVEL OF SOVEREIGNTY: LOW
Dedicated
DEVELOPMENT COST: LOW
SECURITY RISK: LOW
LEVEL OF CONTROL: MEDIUM
LEVEL OF PRIVACY: MEDIUM/HIGH
LEVEL OF SOVEREIGNTY: VARIABLE

22. authentiq.com
Choosing an Authorization Server
22
Self-built Off-the-shelve Social Dedicated
Type Internal Internal External External
Sign in/up UX
User needs to enter
profile information
User needs to enter profile
information
User can share (part of)
existing profile
User can share (part of)
existing profile
Life cycle UX
Worry about account
recovery
Managed account life cycle Managed account life cycle Managed account life cycle
API Tokens Manage own API tokens Managed API tokens Managed API tokens Managed API tokens
Toxic data
Personal data stored on-
site
Personal data stored on-site Personal data stored at IdP Personal data stored at IdP
Privacy
Full control over user
tracking
Full control over user tracking Risk of external user tracking
Variable control over user
tracking
Security Passwords Passwordless, 2FA, … Passwordless, 2FA, … Passwordless, 2FA, …

23. authentiq.com
OpenID Connect & OAuth 2.0
23
For mobile apps.

24. authentiq.com
Mobile OAuth Recipe
1.Register app as a public client at IdP
2.Register your redirect URI as a Universal Link
3.Don’t use an embedded browser
4.Don’t use the implicit flow
5.Protect the authorization code (using PKCE)
24

25. authentiq.com
Register app as a public client
• Client doesn’t authenticate to the server; no client secret
• Client needs to register the full redirect URI
• Client should use measures to protect the authorization code
25

26. authentiq.com
Register your inter-app redirect URL
• Custom URI schemes
com.your.app:/authorized/<provider>
• Universal Links
https://ul.your-domain.example/authorized/<provider>
• Loopback redirects
http://127.0.0.1:50719/authorized/<provider>
26

27. authentiq.com
Don’t use an embedded browser
• An embedded WebView allows app to read the user’s credentials
• An external user agent facilitates single sign-on (SSO)
• App/Play stores might scan for this in the future
27

28. authentiq.com
Don’t use the implicit flow
• Might seem appropriate for a
public client, but…
• No refresh token, so user needs
to re-authenticate
• Other apps might hijack the
returned tokens
28
No client
secret! But…

29. authentiq.com
Protect the authorization code
• Another app might intercept the authorization code
• Proof Key for Code Exchange (RFC 7636)
• Pass in the (partial) hash of a secret to the /authorize request
GET /authorize?response_type=code&code_challenge=AAA
• Then present the full secret to the /token request
POST /token
grant_type=authorization_code&client_id=YYY&code=ZZZ&code_verifier=BBB
• Required for public clients on mobile devices
29

30. authentiq.com
We now have
• An ID Token, to identify the user
• An Access Token, to retrieve their profile
• A Refresh Token, to renew expired access tokens
30

31. authentiq.com
API Authorization
31
Authorization: Bearer {access_token}

32. authentiq.com
Two types of Bearer tokens
• By introspection, using opaque tokens (RFC 7662)
• Resource server needs to call the token issuer for validation
• Tokens can be revoked
• Via JWT validation, using structured tokens (RFC 7519)
• Resource server only needs public key of the token issuer
• Tokens can’t be revoked
32

33. authentiq.com
Token introspection (RFC7662)
• Resource server asks the IdP whether a token is (still) valid
• POST /introspect
token=abcdefg
{
"active": true,
"client_id": "l238j323ds-23ij4",
"username": "jdoe",
"scope": "read write dolphin",
"sub": “Z5O3upPC88QrAjx00dis",
"aud": "https://protected.example.net/resource",
"iss": "https://server.example.com/",
"exp": 1419356238,
"iat": 1419350238,
"extension_field": "twenty-seven"
}
33

34. authentiq.com
JWT Token validation
• Token is a JWT containing sub, aud, iss claims
• Obtain the public key of the IdP
Probably from /.well-known/openid-configuration
• Validate it locally with favourite language
claims = jwt.decode(token, issuer_public_key,
audience=“https://my-api-server/",
allowed_algorithms=[“RS256”])
34

35. authentiq.com
Conclusion
• Good and bad onboarding patterns
• OIDC for authentication
• OAuth 2.0 for API Authorization
• Future talk: User Managed Access (UMA)
35

36. Questions?

37. Thank you
https://www.authentiq.com/