In this talk, we'll dive into the basics of authentication from an asp.net developer's perspective. If words like "JWT", "claims", "OAuth", "OpenID", "authentication server", "refresh tokens" etc confuse you, then this talk is for you. We'll also peek into identity platforms like Auth0, Okta, Azure AD B2C, IdentityServer etc which are commonly used with asp.net. Finally we'll walk through some best practices and checklists. All slides & code samples will be publicly shared after the presentation. Author: Mithun Shanbhag

1. twitter: @MithunShanbhag
blog: mithunshanbhag.github.io

2. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
OpenID Connect (OIDC) vs OAuth 2.0
OpenID Connection (OIDC)
• Authentication protocol (SSO)
• Built on OAuth 2.0
• Generates id_token
• Standardizedscopes
OAuth 2.0
• Authorization protocol
• Generates access_token
• Claimsandcustom claims
image attribution: okta dev blog

3. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
User Client App Authorization Server Resource (API)
Authorization request
Login button
302/Redirectto authentication prompt
Authentication and consent
Calls /authorize endpoint
• client_id: xxxxxxxxxxxx
• redirect_uri: xxxxxxxxxxxxxxx
• state:xxxxxxxxxxxxxxx
• response_type:tokenid_token
• scope: openid
Authorization grant
Requestresource(s)
• access_token
• id_token
• access_token
Response
Implicit Flow
LEGEND
FrontChannel
Back Channel

4. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
DEMO

5. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
AppType Channels User
Interaction
Client
Secret
response_type field Recommended Flow
Single Page Apps Front Yes No “token id_token” Implicit
Server-Side Web Apps Front, Back Yes Yes “code” Authorization Code
Native Apps Front, Back Yes Yes “code” Authorization Code/PKCE
CLI,daemons, services Back No Yes N/A Client Credentials
Legacy Apps Front, Back No No N/A Resource Owner/Password

6. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
User Client App Authorization Server Resource (API)
Authorization request
Login button
302/Redirectto authentication prompt
Authentication and consent
Calls /authorize endpoint
• client_id: {xxxxxxxxxxxx}
• redirect_uri: {xxxxxxxxxxxxxx}
• state:{xxxxxxxxxxxxxxx}
• response_type:code
• scope: openid
Authorization code grant
RequestID and Access tokens
code: {code}
Response
Authorization
Code Flow LEGEND
FrontChannel
Back Channel
Calls /token endpoint
• client_id: xxxxxxxxxxxx
• client_secret: xxxxxxxxxxxxxxx
• code: {code}
• id_token
• access_token
Requestresource(s)
Response
• access_token

7. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
OIDC Endpoints
• GET/authorize: Obtain user consent andauthorization grant.
• POST/token: Obtains id_token, access_token by supplying the authorization code or refresh_token.
• GET/userinfo: Obtains claims about the authenticated end user.
• POST/revoke: Revoke an access_token or refresh_token.
• GET/logout: Self-explanatory.
• GET/.well-known/keys: Obtain public keys (JWKS) used tosign the tokens.
• GET/.well-known/openid-configuration: Return OIDCmetadata related tothe specified authorization server.
• GET/.well-known/authorization-server: Return OAuth 2.0 metadata related tothe specified authorization server.

8. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
JWT Structure
HEADER
• Signing algorithm (mostly RS256/asymmetric orHS256/symmetric).
• Signing Key Id.
PAYLOAD
• Standardandcustom claims.
SIGNATURE
• HS256/symmetric:
• The client secret is used toboth sign & verify.
• Signature = HS256(base64UrlEncode(header)+ "." + base64UrlEncode(payload) + “.”+ secret)
• RS256/asymmetric:
• The private signing key/certificate is used tosign.
• Verification done via the public key (JWKS from/.well-known/keys OIDCendpoint).
• Signature = RS256(base64UrlEncode(header)+ "." + base64UrlEncode(payload) + “.”+ public/private key pair)

9. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
Q&A