The document discusses secure authorization for devices using the OAuth device flow, addressing problems like delegating application access for browserless and input-constrained devices. It outlines the protocol for device authorization and user interaction, emphasizing the importance of user security and privacy. Additionally, it highlights the implementation of OAuth device flow in IdentityServer and its potential applications in various contexts, such as public printers and smart devices.

1. Secure Authorization for your Printer –
The OAuth Device Flow
Scott Brady
@scottbrady91 – Rock Solid Knowledge #devsum18

2. Introductions
• Identity & Access Control Lead @ Rock Solid Knowledge
• Commercial side of the IdentityServer OSS project
• AdminUI
• SAML2P & WS-Federation
• IdentityServer European Partner
• Development, consultancy, support, and training
• Helps fund the IdentityServer project
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

3. The Problem
• SOLVED: Delegating an application access to protected resources on
behalf of user (OAuth 2.0)
• SOLVED: Verifying the identity of the resource owner who delegated
access (OpenID Connect 1.0)
• How to delegate access to:
• Browserless devices
• Input constrained devices
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

4. Browserless Devices
• Smart TVs
• Internet of Things
• Printers
• Fridges
• Sensors
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

5. Input Constrained Devices
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

6. User
Client
Protected Resource
Authorization
Server
Authorization
Request
Authorization
Grant
Authorization
Grant
Access
Token
Request
Protected Resource
Trust
Authentication
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

7. Resource Owner Password Credentials?
@scottbrady91 – Rock Solid Knowledge (identityserver.com)
POST /token
grant_type=password
&client_id=oauth_client
&username=scott
&password=Password123!
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600
}

8. Resource Owner Password Credentials?
• No browser necessary
• Impersonation
• No scoped access
• Exposes user credentials to device
• Breaks when we add phishing resistant credentials
• No federation (unless using “benevolent phishing”)
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

9. Solution
The OAuth Device Flow
• Uses an external browser to bridge the gap
• (your smartphone)
• User authentication external to the device
• Currently in draft 9:
• datatracker.ietf.org/doc/draft-ietf-oauth-device-flow
• Already in use by Google
• Similar implementations available, but now there’s a spec!
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

10. Demo!
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

11. Device
User Secondary
Device
Authorization
Server

12. The Protocol
Device Authorization (Request)
POST /device_authorization HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
client_id=459691054427
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

13. The Protocol
Device Authorization (Response)
{
"device_code": "GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
"verification_uri": "https://www.example.com/device",
"user_code": "WDJB-MJHT",
"verification_uri_complete":
"https://www.example.com/device?user_code=WDJB-MJHT",
"expires_in": 1800,
"interval": 5
}
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

14. The Protocol
User Interaction
+-----------------------------------------------+
| |
| Using a browser on another device, visit: |
| https://example.com/device |
| |
| And enter the code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

15. The Protocol
User Interaction
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

16. The Protocol
Token Request
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8
&client_id=459691054427
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

17. The Protocol
Token Request
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
}
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

18. Extras
• OpenID Connect
• Refresh tokens
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

19. Proof of Concept Code
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

20. IdentityServer4 & Device Flow
• Open Source (part of the core repository)
• Hopefully available in v2.next
• Consent page may have to come later…
• Otherwise v3
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

21. @scottbrady91 – Rock Solid Knowledge (identityserver.com)
IdentityServer4 & Device Flow

22. Security Considerations
User Codes
• Shorter codes are better for the user
• Longer codes are better for security
• Numeric is better for the user
• Alphanumeric is better for security
• What’s the worst that could happen?
• Breach of privacy
• Something embarrassing…
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

23. Security Considerations
User Interaction
• Phishing for credentials
• Phishing for tokens
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

24. Further Use Cases
• Public printers
• Bringing strong authentication to native devices
• Screenless devices
• Virtual assistants?
• Device Pairing
@scottbrady91 – Rock Solid Knowledge (identityserver.com)

25. Don’t forget to evaluate this session in the DevSum app!
@scottbrady91 – Rock Solid Knowledge #devsum18
Thanks!
@scottbrady91
www.identityserver.com