Security Architectures & Security Protocols – Working with Software Development Teams (ISVs and in-house) • Co-Creator of IdentityServer & IdentityModel OSS Project – Certified OpenID Connect & OAuth 2.0 Implementation for .NET – https://identityserver.io • Co-Creator of PolicyServer – Authorization for modern Applications – https://policyserver.io email dominick.baier@leastprivilege.com blog https://leastprivilege.com twitter @leastprivilege slides https://speakerdeck.com/leastprivilege
Sign-on • Single Sign-on • Sign-out? • User management • Access management external Authentication • "Social" providers • Integration with identity systems of customers 3rd Party Access/Integration • Access to your system by 3rd parties • Integration with existing 3rd party software App1
– profile: first name, last name… – email: email, email verified • API resources – logical name of API the client wants to access The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. The value of the scope parameter is expressed as a list of space-delimited, case- sensitive strings. RFC6749
• username/password • New App (SPA) • Mobile App • Customers • username/password • Google • customer identity system • Back-office System (Web) • Employees • Automated jobs • service accounts Clients Resources • Monolith • Products API • Customers API • Invoicing API • …
at the Issuer. OIDC Core: 5.1 Standard Claims Bad Examples: • dominick_baier • dominick@baier.com • dominick\domain • <id column of your SQL Server users table> Good Example: • <something_random>
Provider External Identity Providers my sub/issuer + other claims sub/issuer + other claims my sub -> ext sub + issuer + other claims mapping • Pros • clients become agnostic of tech details • Cons • more complicated STS implementation • mapping logic • who's the authoritative data source?
single flow for interactive clients – authorization code flow w/ PKCE • Works for all user-centric client types – public and confidential – web and native – optional client authentication • "OAuth 2.1" will deprecate the other flows – implicit and password
a certain degree – session id distributed via identity token – front- and back-channel notifications • Common discussion topics – what does logout mean to you? • applications, identity provider, upstream identity provider… – client- vs server-side sessions – shared inactivity timer
identifying a resource (aka Web Service) – only single resource could be specified • OAuth uses the scope parameter The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. The value of the scope parameter is expressed as a list of space-delimited, case- sensitive strings. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. RFC6749
What's the best value for the access token lifetime? – as short as possible • Do you need revocation? – no – yes – waiting until current access token expires is OK – yes – immediate
• refresh token (optional) • lifetime: >n seconds • absolute vs sliding expiration • what can be revoked: • refresh token • max time to revocation • n seconds • token service round-trip for refresh • every n seconds • token service round-trip for validation • 0 Self-contained Token (JWT) Reference Token • token lifetime: n seconds • refresh token (optional) • lifetime: >n seconds • absolute vs sliding expiration • what can be revoked: • access token • refresh token • max time to revocation • immediate • token service round-trip for refresh • every n seconds • token service round-trip for validation • for every usage
system – users – clients – resources • Solid design around subject identifier • Keep as simple as possible – number of claims / types – session management requirements – resource design – resource access and revocation
Dominick Baier
leastprivilege
reverentgeek
rmw
skipperchong
carmenhchung
keathley
productmarketing
clairelew
thoeni
jcasabona
