2. Agenda
• Overview of token-based authentication.
• Types of tokens.
• Anti-CSRF.
• Access.
• Refresh.
• Token formats.
• Standards and Guidelines.
• Demo.
• Resources
3. Overview
• Token-based authentication is the process of verifying a user’s
identity then creating and returning a unique set of claims (i.e. key-
value pairs) that describe the user.
• Token-based authentication allows you to outsource authentication
from your application and instead consume a token based on a
trusted relationship between your app and an identity provider.
4. Anti-CSRF “sync” Tokens
• Use if you’re relying on cookies for authentication – e.g. ASP.NET’s
forms authentication ticket.
• Websites that use any persistent authentication mechanism such as
Windows Authentication, Basic, etc. can also be subject to CSRF
attacks and should use sync tokens.
• Sync tokens are random-generated values included in any
form/request and are based on the synchronizer token pattern. This
pattern utilizes two anti-CSRF tokens submitted to the server with
each HTTP POST: one token as a cookie and the other as a form
value. When the tokens are submitted, the server compares the two
and allows the request to proceed only if both tokens pass a
comparison check.
5. Anti-CSRF Tokens – cont’d
• In a claims-based application, ASP.NET will generate and validate these
tokens based on the current user’s identity. This identity is established by
WIF and available via the IIdentity interface.
• Denote the unique claim in your app if you’re using something other than
NameIdentifier. Add a line similar to the following line in the Application_Start
method in Global.asax.cs:
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;
• OWASP provides a good explanation of these tokens along with links to the
Microsoft implementations in this article:
https://www.owasp.org/index.php/Anti_CSRF_Tokens_ASP.NET.
• ASP.NET MVC example:
<input name="__RequestVerificationToken" type="hidden"
value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs"
/>
6. Access Tokens
• An access token is just an opaque string representing an
authorization granted to a client application.
• Access tokens can be Bearer or Holder-of-Key tokens.
• Bearer tokens can be used as-is without requiring proof of ownership.
• Used by passive, browser-based clients.
• Must be transmitted over SSL/TLS to prevent man-in-the-middle attacks.
• Refer to OAuth spec: https://tools.ietf.org/html/rfc6750.
• Holder-of-Key tokens require supporting cryptographic material to prove token
ownership.
• Guarantees end-to-end message key security since the token is signed and encrypted
and keys are shared out-of-band.
• Refer to OAuth spec: https://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01.
7. Access Tokens – cont’d
• Format explained:
access_token: string containing the token issued by the identity provider.
token_type: the type of token issued.
expires_in: the lifetime in seconds of the access token.
scope: optional parameter defining which parts of protected resources can be accessed on
behalf of the user.
state: optional parameter used for security checks. Value sent by the client is the same
one returned in the response.
refresh_token: optional parameter used to request a new access token.
• Example:
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
8. Refresh Tokens
• An opaque string containing an unique identifier used to retrieve
authorization information for a specific client.
• Refresh tokens are presented to an authorization server by a client
when the access token becomes invalid or expires.
• Refresh tokens are long-lived as compared to access tokens whose
lifetime is much shorter.
• Refresh tokens should be able to be revoked in case an access token is
compromised.
10. Token Formats
• SAML – Security Assertion Markup Language.
• JWT – JSONWebToken.
• SWT – Simple WebToken.
SAML SWT JWT
Format XML HTML Form Encoding JSON
Designed For SOAP REST REST
Default WIF Implementation Yes No No
Protocols WS-Trust &WS-Federation OAuth 2.0 OAuth 2.0
Support for Signing Yes Yes Yes
Support for Encrypting Yes No Yes
11. Standards and Guidelines
• OpenID Connect is the authentication spec built on top of OAuth 2.0.
It covers the use and format of the JSONWebToken. Refer to:
http://openid.net/specs/openid-connect-core-1_0.html.
• OWASP has good coverage of topics related to security and
authentication:
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet.
• https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet.
• JSONWebToken specification: https://tools.ietf.org/html/draft-ietf-
oauth-json-web-token-32.
