Dette innholdet er ikke tilgjengelig på ditt språk, men her er den engelske versjonen.
This documentation is archived and is not being maintained.

Token Formats Supported in ACS

Published: April 7, 2011

Updated: June 19, 2015

Applies To: Azure

When your web applications and services handle authentication with Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS), the client must obtain a security token issued by ACS to log in to your application or service. ACS can issue security tokens in the following formats:

ACS can issue security tokens in any of the following formats. The token format that ACS uses for a web application or service is determined by the relying party application configuration. For information about configuring relying party applications, see Relying Party Applications.

Security Assertion Markup Language (SAML) is the oldest and the most common format of tokens in use today for single sign-on (SSO) and claims-based identity. SAML specifies an XML format, for tokens as well as protocols, for performing a web application or a web service SSO using SAML tokens. For more information about SAML tokens, see SAML Specifications (http://go.microsoft.com/fwlink/?LinkID=213719).

SAML 1.1 and SAML 2.0 tokens are widely supported by a number of development platforms, including Windows Identity Foundation (http://go.microsoft.com/fwlink/?LinkID=213729).

The following is an example of a SAML token.

<assertion id="_4fe09cda-cad9-49dd-b493-93494e1ae4f9" issueinstant="2012-09-18T20:42:11.626Z"
    version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:canonicalizationmethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:signaturemethod algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
        <ds:reference uri="#_4fe09cda-cad9-49dd-b493-93494e1ae4f9">
                <ds:transform algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                <ds:transform algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:digestmethod algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
    <keyinfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>       <X509Certificate>MIIDCDCCAfCgAwIBAgIQRmI8p7P/aphMv5Kr9vQpqTANBgkqhkiG9w0BAQUFADAtMSswKQYDVQQDEyJBQVJPTkJPT0subnRkZXYuY29ycC5taWNyb3NvZnQuY29tMB4XDTEyMDUyMTIzMjMxMFoXDTEzMDUyMTAwMDAwMFowLTErMCkGA1UEAxMiQUFST05CT09LLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI79l6EOSWswJn3d9i4yfZh9Cwo2XNhb4tOWvmljCKFlrWoz/Drch5aOzdmI/yFaqkyX7BXc/zoSmX1n3VkqHIeJkGECcZX2bD4jPuICVmKBcXo0SeQ+2vF6DoqjVKaegWrPsqmDrlCscnlMLb11Fg1Ffqkm8wyyWwbQvC5VnVf0i9DPE0n+i3NJi9cT57obrNRkQzwfBZy08I2JlpxLfaUUDhHlF99C1MtBduzn3au+S20gom1cHAcSvHBormXbjPZ5F6RJUz7kO/U+M5rYkiS+vtANtnBlUAK8fRmEUrYFRMr1tyiOXcRid/7UJP3e0EmAsneMnuD9WO/mK6MuzIECAwEAAaMkMCIwCwYDVR0PBAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQBCRM9maY5ZE+wIxefxjT0IAqp7H6l062PKOGdld5MapOJUWbng2CrfUV3YI5OSD9yhevgDne3jf2DUBv5QndHdms+FL260ydDmwet4A5kJi3ZBO4sR/PZTz3FdeeOwdTeUS2wAMJuphAZ1+PUVk25bbEu/DKmgeYzRn64CHWqk5sPKzH9jAszvX2EeoClI+8Sp/bXHTwzEUOFYcicPOO+tuFTqHOYBDT5bE42rAp/SaC1wXbmTCGS12gfCZCrlml6LZNTsKQWBF2szXOPGcFcInGkauZDUUtZd+921uy0E/sYwgNfi8phU1aGZjIESVFQ70LpfvIMwF6++BRX12icW</X509Certificate>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
    <conditions notbefore="2012-09-18T20:42:11.610Z" notonorafter="2012-09-18T21:42:11.610Z">
        <Attribute Name="http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider">

Simple Web Token (SWT) tokens comply with the SimpleWebToken specification. SWT tokens are expressed as form-encoded key/value pairs signed with a cryptographic key. The specification mandates the presence of some key/value pairs, but it leaves room for application-specific key/value pairs. The keys that are always present in an ACS-issued SWT token are shown in the following table.


Key Description


A representation of the ACS service namespace that issued the token. The pattern for this value is https://<servicenamespace>.accesscontrol.windows.net/.


The value of the applies_to used to request the token. This value is either an HTTP or HTTPS URI.


The Epoch time upon which the token expires.


The HMACSHA256 signature of all the other key/value pairs. This key/value pair is always the last key/value pair in the token. The form-encoded representation of the other key/value pairs (including application-specific claims) is signed.

In addition to these key/value pairs, ACS adds one or more claims to a token before issuance. These claims are driven by the rule configuration present in ACS at the time of the token request. All such claims have a type and one or more values, where both the type and the values are strings. When a claim contains more than one value, the values are separated by the comma (“,”) character. Claims are encoded as key/value pairs, exactly as the key/value pairs described in the previous table.

The following is an example of an ACS token that contains claims represented as key/value pairs.


With the exception of the HMACSHA256 key/value pair, these pairs can be in any order. The following ACS token is equivalent to the previous ACS token except for the signatures that are different.


The following table shows the contents of the token with URL decoded values.


Source Key URL encoded value URL decoded value

User-defined Claims






Contoso Corporation

System-defined Claims













JSON Web token (JWT) support is being added in beta, this means that there can be breaking changes without notice.

The ACS implementation of the JWT token format follows the draft 9 of the JWT specification. For more information, see http://go.microsoft.com/fwlink/?LinkID=253666. Similar to SWT tokens, JWT is a compact token format that is suited for REST web services. Unlike the SWT format, JWT supports a variety of signing options. ACS supports both symmetric and asymmetric signatures for JWT tokens. The claims that are always present in ACS-issued JWT tokens are shown in the following table.


Claim Claim Type used JWT Description



A representation of the Access Control namespace that issued the token. The pattern for this value is https://<namespace>.accesscontrol.windows.net/



The value of the scope used to request the token. This value is used to identify the intended recipient of the token.

Not Before


The Epoch time before which the token is not valid.



The Epoch time upon which the token expires.

The following algorithms are supported for JWT tokens:


Algorithm identifier in JWT header Description


HMAC using SHA-256 hash algorithm. For signing JWT with a symmetric key .


RSA using SHA-256 hash algorithm. For signing JWT an asymmetric key, using an x509 with certificate.

Here is an example of a JWT token:


JWT is composed of segments, which are delimited using ‘.’. The following table shows the decoded segments of a JWT token:


JWT Segment Value

JWT Header


JWT Claim Set




A single claim with multiple values is represented as a JSON array. For example if a user is a member of multiple roles, the role claim would appear as follows:

“role”: [ “admin”, “user” ]

When a SAML 2.0, SAML 1.1, SWT, JWT token is issued, ACS uses various standard protocols to return the token to a web application or service. ACS supports the following token format/protocol combinations:

  • ACS can issue and return SAML 2.0 tokens over the WS-Trust and WS-Federation protocols (depending on the protocol used in the token request).

  • ACS can issue and return SAML 1.1 tokens over the WS-Federation and the related WS-Trust protocols (depending on the protocol used in the token request).

  • ACS can issue and return SWT tokens over the WS-Federation, WS-Trust, and OAuth WRAP or OAuth 2.0 protocols, (depending on the protocol used in the token request).

  • ACS can issue JWT tokens over the WS-Federation, WS-Trust, and or OAuth 2.0 protocols, (depending on the protocol used in the token request).

See Also