Back Matter

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Appendix A: Glossary

The following is a list of terms and their definitions as they are used in this book.

Access Token – In the context of OAuth 2 and OIDC, a security token used by an application to access protected resources such as an API.

Account – A construct within a software application or service that usually contains or is associated with identity information and optionally privileges and which is used to access features within the application or service.

Application – A software application that issues requests to a server.

Application Programming Interface (API) – A software service interface that allows a client program to request resources or actions from the software service.

Authorization Code – In the context of OAuth 2 and OIDC, an intermediary, opaque code returned to an application and which represents the application’s authorization by the user to call an API on the user’s behalf. It is used to obtain security token(s).

Authorization Server – A service which implements the OAuth 2 protocol and enables resource owners (users) to authorize applications to access content they own at resource servers and which issues security tokens enabling the authorized access.

B2B (Business to Business) – A business model where services are targeted to businesses that use the services in some way to deliver a service to their customers.

B2C (Business to Consumer) – A business model where services are targeted to consumers who typically act on their own behalf.

B2E (Business to Employee) – A business model where services are targeted to businesses where the users are the employees of the businesses and act on their employer’s behalf.

Back-Channel – Communication sent directly from one component, typically a back-end server, to another back-end server, as opposed to being sent via HTTP redirects, with a user’s browser as an enabling intermediary. Compare to front-channel.

Browser-Based Application – See the definition for single-page application.

Client – In the context of OAuth 2 and OIDC, an application that requests access to protected resources on behalf of the owner of those resources.

Confidential Client – In the context of OAuth 2 and OIDC, an application that runs on a protected server which enables it to securely store confidential secrets with which to authenticate itself to the authorization server.

Directory Server – A repository for storing, managing, and organizing information about resources. Directory server products have often been optimized for storing information that is frequently read but infrequently modified and used to store information about entities such as users, access control privileges, application configurations, and network printers. Information in directory services has been used for authentication and authorization of users.

End User or User – A human subject using applications or services and who is authenticated and authorized when accessing protected resources.

Front-Channel – Communication sent via HTTP redirects, with a user’s browser as an enabling intermediary, instead of directly from one back-end server to another back-end server. Compare to back-channel.

HS256 – Hash-based message authentication code (HMAC) using SHA256 hash function. A symmetric cryptographic algorithm that can be used for creating and validating a digital signature. It is one option for signing a JSON Web Token, but requires both the issuer and validator of the token to know the same secret.

Identifier – A single identifying attribute that points to a unique individual user or entity, within a particular context.

Identity – A set of attributes, including one or more identifiers, associated with a specific user or entity, in a particular context.

Identity Proofing – The process of vetting a user’s identity and profile information.

Identity Provider (IdP) – (1) A general term for an entity providing an identity service designed to authenticate users and provide assertions about an authenticated user and the authentication event. (2) In the context of the SAML 2 cross-domain single sign-on profile specification, a server which issues SAML 2 assertions about an authenticated subject and authentication event.

Identity Repository – A collection of users stored in a computer storage system, such as a database or directory service.

ID Token – In the context of OIDC, a token used to convey claims about an authentication event and an authenticated entity to a relying party (application).

Internet of Things (IoT) Device – A network-attached device that has an IP address and is capable of transferring information over a network without human interaction. Usually refers to dedicated-purpose devices such as sensors or smart appliances as opposed to general computing devices such as computer servers.

Least Privilege – A security principle of granting the minimum privilege level required for a task or operating at the lowest possible privilege level for a task.

Mobile Application – An application that executes on a mobile device as a native application.

Multitenant Application – An application deployment shared by multiple independent customers whose data is segmented into their own area of the application’s data storage. The separation between different customers’ data is enforced by the application and its storage, rather than the network.

Native Application – An application installed and run natively on a computing device.

OpenID Provider – In the context of OIDC, an OAuth 2 authorization server that authenticates a user and returns claims about the user and authentication event to a relying party (application) in accordance with the OIDC specification. Applications can delegate user authentication to an OpenID Provider.

Public Client – In the context of OAuth 2 and OIDC, an application that executes primarily on the user’s client device or in the client browser and cannot securely store secrets with which to authenticate itself to an authorization server.

Refresh Token – In the context of OAuth 2 and OIDC, a token that can be used by an application to request a new access token when a prior access token has expired or become invalid. With OIDC, a refresh request can optionally return an ID Token as well.

Relying Party – An entity that delegates authentication to an Identity Provider or OpenID Provider or delegates authorization to an authorization server and, in either case, relies on the results, usually in the form of security tokens. With OAuth 2, an API is a relying party, and with OIDC and SAML 2, an application is a relying party.

Resource Owner – In the context of OAuth 2, a user that authorizes access to protected resources hosted at a resource server.

Resource Server – In the context of OAuth 2 and OIDC, an entity that contains protected resources.

RS256 – RSA Signature with SHA256 hash algorithm. An asymmetric cryptographic algorithm that can be used for creating and validating a digital signature. It is one option for signing a JSON Web Token and, unlike HS256, does not require that the issuer and validator of the token know the same secret.

Security Domain – A security domain is a logical construct that defines the boundaries of one entity’s control or ownership.

Service Provider – (1) A general term for an entity providing a service, such as an application, to a user. (2) In the context of the SAML 2 cross-domain single sign-on profile specification, a client entity which requests SAML 2 assertions about an authenticated subject and authentication event.

Single-Page Application (SPA) – An application with logic that executes primarily in a browser, by dynamically altering the displayed web page, rather than making requests to a server to render new pages to respond to user actions. A SPA is assumed to be a public client, as defined by OAuth 2.

Tracking Prevention – A set of features implemented by browsers to limit the ability of third parties to track users’ activity across different websites.

User – See the definition for the end user.

User Consent – In the context of provisioning an account for a user, the process through which an end user is asked to provide their consent for the collection and processing of their personal data. In the context of OAuth 2, the process through which a user provides their consent to authorize an application to access protected resources on their behalf.

Web Application or Traditional Web Application – An application with logic that executes primarily from a protected server, by rendering new pages from the server to respond to user actions. Traditional web applications are assumed to meet the definition of a confidential client, as defined by OAuth 2.

Appendix B: Resources for Further Learning

This appendix lists resources which may be helpful for further learning.

B.1. OAuth 2 – Related Specifications

OAuth 2.1 Authorization Framework (draft as of this writing) – Consolidates several OAuth-related specifications since the original OAuth 2.0 specification:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-06

OAuth 2.0 Authorization Framework (original specification):

https://tools.ietf.org/html/rfc6749

OAuth 2.0 Threat Model and Security Considerations:

https://tools.ietf.org/html/rfc6819

OAuth 2.0 for Browser-Based Apps (draft as of this writing):

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps

OAuth 2.0 for Native Apps:

https://tools.ietf.org/html/rfc8252

OAuth 2.0 Security Best Current Practice (draft as of this writing):

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

OAuth 2.0 Device Authorization Grant:

https://datatracker.ietf.org/doc/html/rfc8628

OAuth 2.0 Authorization Framework: Bearer Token Usage:

https://tools.ietf.org/html/rfc6750

Proof Key for Code Exchange by OAuth Public Clients:

https://tools.ietf.org/html/rfc7636

OAuth 2.0 Token Introspection:

https://tools.ietf.org/html/rfc7662

OAuth 2.0 Token Revocation:

https://tools.ietf.org/html/rfc7009

OAuth 2.0 Pushed Authorization Requests (PAR):

https://datatracker.ietf.org/doc/html/rfc9126

OAuth 2.0 Rich Authorization Requests (RAR): (draft as of this writing)

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar

JWT-Secured Authorization Requests (JAR):

https://datatracker.ietf.org/doc/html/rfc9101

B.2. JWT

JSON Web Token (JWT):

https://tools.ietf.org/html/rfc7519

JSON Web Encryption (JWE):

https://datatracker.ietf.org/doc/html/rfc7516/

JSON Web Signature (JWS):

https://datatracker.ietf.org/doc/html/rfc7515

B.3. OIDC

OIDC Specifications:

https://openid.net/connect/

B.4. SAML

SAML specifications. See especially the core, bindings, and profile specifications:

https://wiki.oasis-open.org/security/FrontPage

Security Assertion Markup Language (SAML) V2.0 Technical Overview:

www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

SAML Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0:

http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants:

https://datatracker.ietf.org/doc/html/rfc7522

B.5. Multi-factor Authentication

The FIDO Alliance:

https://fidoalliance.org/fido2/

WebAuthn:

www.w3.org/TR/2019/REC-webauthn-1-20190304/

B.6. Background Information

An explanation of cookies, including security guidance:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Explanation of Cross-Origin Resource Sharing (CORS):

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Brief outline of different approaches to authorization and access control:

https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7316.pdf

OWASP Top 10 – Critical security risks for web applications and how to avoid them:

www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

OWASP SAML Cheat Sheet:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SAML_Security_Cheat_Sheet.md

Two sites on open redirects:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md

https://cwe.mitre.org/data/definitions/601.html

Checking for breached passwords – I’ve Just Launched “Pwned Passwords” V2:

www.troyhunt.com/ive-just-launched-pwned-passwords-version-2

B.7. Privacy

A map showing the location and strength of privacy legislation around the world:

www.dlapiperdataprotection.com/

This website presents the articles of the GDPR in a convenient fashion:

https://gdpr-info.eu/

Appendix C: SAML 2 Authentication Request and Response

SAML 2 authentication request and response messages contain a lot of information. We’ve assumed that most developers are using an SDK or authentication broker rather than implementing SAML 2 directly in their applications, and therefore their primary need is to understand SAML 2 requests and responses for troubleshooting purposes and to understand validation steps. As explained in Chapter 16, the best way to debug issues with SAML 2 is to capture an HTTP trace, extract the SAML 2 request and/or response, and examine it. In the following sections, we’ll explain which fields to examine and what to look for.

C.1. SAML 2 Authentication Request

When an application needs a user authenticated by a SAML 2 identity provider (IdP), the application redirects the user's browser to the identity provider with a SAML 2 authentication request message. An authentication request message can vary substantially as many elements are optional. A sample request without a signature might look like the following (text in bolded italics has been substituted for the actual values):

<samlp:AuthnRequest

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

Destination="IDP URL"

ID="ID"

IssueInstant="TIME ISSUED"

ProtocolBinding=

"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

Version="2.0"

ProviderName="SERVICE PROVIDER"

AssertionConsumerServiceURL="ACS URL">

<saml:Issuer>SERVICE PROVIDER</saml:Issuer>

</samlp:AuthnRequest>

The request elements we have found most useful to check when troubleshooting SAML 2 are shown in Table C-1, along with an explanation for each. A given request may have more or fewer elements, depending on a particular service provider’s configuration or implementation.

Table C-1

Useful SAML 2 Authentication Request Elements

Name	Purpose
AssertionConsumerServiceURL	URL at the service provider to which the identity provider’s authentication response message should be sent. Often called the “ACS” URL.
AuthnRequest	Type of request. In this case, a request to authenticate a user.
Destination	URL for the recipient of the request, in this case, the IdP. This element was designed to prevent forwarding of messages to unintended recipients. This value must match the URL at which the request was received.
ForceAuthn	Can be used by requestor to indicate the IdP should prompt the user for credentials, regardless of the state of the user’s session at the IdP.
ID	The ID is a unique identifier for each request. When an IDP responds, the value of the InResponseTo element of the response should match the ID for the request that triggered the response.
Issue Instant	The time at which the request was issued. Identity providers should reject requests that are outside a certain time tolerance.
Issuer	Entity which generated the request, namely, the SAML 2 service provider. The IdP should check to make sure a request’s Issuer element matches a registered service provider.
NameIDPolicy	Can be used by the service provider to specify the type of identifier to use in identifying the authenticated user. Using an email address is common, but can conflict with privacy requirements.
ProtocolBinding	The requested mechanism by which the SAML response message should be sent over an underlying transport protocol. In practice, HTTP-POST is often used to avoid issues with browser URL size limits.
ProviderName	Human-readable name of entity issuing the SAML 2 request (the service provider).
RequestedAuthnContext	Can be used by a requestor to specify requirements for the authentication context used by IdP when authenticating the user. Can be used to request a type or strength level of authentication, as agreed between the service provider and IdP.
Signature	Signature information if a request has been signed by the issuer.
Subject	Used to specify the desired subject (user) for the requested authentication assertion.
Version	The version should be “2.0” for SAML 2.

A SAML 2 service provider (application) can send a SAML 2 request to an identity provider using a few different bindings. These indicate the mechanism for sending the message over underlying transport protocols. In practice, the HTTP-Redirect and HTTP-POST bindings are commonly used because they do not require direct network connectivity between the service provider and the identity provider. The HTTP-Redirect binding can be used with SAML 2 requests that are not digitally signed, but production environments are recommended to use signed requests to prevent request tampering. If a request is digitally signed, it typically needs to be sent using the HTTP-POST binding to avoid issues with browser URL size limits. The response or assertion from the identity provider must be digitally signed. Due to the size of a signed response, the HTTP-POST binding is typically used for responses.

C.2. SAML 2 Authentication Response

When an identity provider receives an authentication request, it will authenticate the user, if necessary, and return an authentication response to the service provider in the form of a SAML 2 response message which contains a SAML 2 assertion. In the case of an IdP-initiated flow, an IdP may send an unsolicited authentication response to a service provider. The SAML 2 response is an XML message with several components. The exact contents of the response can vary somewhat, depending on the nature of the request, the IdP configuration, and the information returned. Figure C-1 shows the high-level anatomy of a typical SAML 2 authentication response message to help you understand the structure of these often lengthy messages. (Note: A Signature element can be associated with an Assertion, the Response, or both. We have shown it in the Assertion for this sample.)

Figure C-1
Structure of a Sample SAML 2 Authentication Response

A sample SAML 2 authentication response is shown in the following sections. We’ve replaced specific values with explanatory text in bolded italics and provided a table after each snippet to indicate what’s useful to check when debugging.

C.2.1. Response

A SAML 2 authentication response message starts off with “samlp:Response” and includes the information shown in the snippet that follows and explained in Table C-2:

<samlp:Response

xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

ID="ID"

InResponseTo="ID OF CORRESPONDING REQUEST"

Version="2.0"

IssueInstant="TIME ISSUED"

Destination="ACS URL of Service Provider">

<saml:Issuer

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ISSUER OF RESPONSE – IDENTITY PROVIDER

</saml:Issuer>

<samlp:Status>

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</samlp:Status>

Table C-2

SAML 2 Authentication Response Elements Useful for Troubleshooting

Element	Description
ID InResponseTo	A unique identifier for a response. This response element should match the ID of the authentication request which triggered the response (for service provider–initiated cases).
IssueInstant	Time at which the response was issued. This can be checked for correct time to detect time skew issues. Service providers should reject responses that are older than a configured time tolerance.
Destination	The Assertion Consumer Service (ACS) URL where the service provider receives the response. Service providers should validate that the Destination URL in the response is where they received the response.
Issuer	The issuer of the response. Should match the expected identity provider.
Status	The Status element contains the result of the authentication request. Successful authentication is required for a status of “Success.”

C.2.1.1. Authentication Assertion (Beginning)

The beginning of the assertion element of a response contains an ID, the instant at which the assertion itself was issued, and the identity of the assertion issuer as shown in the following snippet and explained in Table C-3:

<saml:Assertion

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

Version="2.0"

ID="ID FOR ASSERTION"

IssueInstant="TIME ASSERTION ISSUED">

<saml:Issuer>ENTITY ISSUING ASSERTION</saml:Issuer>

Table C-3

SAML 2 Authentication Assertion Elements Useful for Troubleshooting

Element

Description

IssueInstant

A unique identifier for an assertion.

Time at which the assertion was issued. This can be checked for correct time to detect time skew issues. Service providers should reject responses that are older than a configured time tolerance.

Issuer

The issuer of the response. Should match the expected identity provider.

C.2.1.2. Digital Signature for Authentication Assertion

The digital signature provides integrity assurance for the signed element. The IdP must sign either the assertion or the response when the HTTP-POST or HTTP-Redirect binding is used and can sign both. The typical elements to check are shown in Table C-4. Portions of this element are not shown for brevity.

<Signature

xmlns:="http://www.w3.org/2000/09/xmldsig#">

...

<SignatureMethod Algorithm=

"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

...

</SignedInfo>

<SignatureValue>DIGITAL SIGNATURE</SignatureValue>

<X509Certificate>CERTIFICATE</X509Certificate>

</X509Data>

</KeyInfo>

</Signature>

Table C-4

SAML 2 Assertion Signature Elements Useful for Troubleshooting

Element	Description
SignatureMethod	Check that the signature algorithm used by the IdP is an algorithm accepted by the service provider implementation.
Certificate	Check that the certificate shown is correct for the IdP and matches IdP metadata configured at the service provider.

C.2.1.3. Subject

The Subject element identifies the authenticated user. A very common issue is that an identifier specified by the identity provider in the assertion is different from the identifier expected by a service provider (application) for the user. The typical elements to check are shown in Table C-5.

<saml:Subject>

<saml:NameID

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">USER IDENTIFIER

</saml:NameID>

<saml:SubjectConfirmation

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData

NotOnOrAfter="EXPIRATION FOR SUBJECT DATA"

Recipient="SERVICE PROVIDER ACS URL>"

InResponseTo="ID FROM REQUEST"/>

</saml:SubjectConfirmation>

</saml:Subject>

Table C-5

SAML 2 Subject Elements Useful for Troubleshooting

Element	Description
NameID	Contains an identifier for the authenticated user.
NotOnOrAfter	Specified validity period for subject data. This time should not have already passed when the assertion is received.
Recipient	This element should match the ACS URL to which the response was delivered. Used by a service provider to ensure it is the intended recipient of an assertion it receives.
InResponseTo	This element should match the ID of the authentication request which triggered the response (for service provider–initiated cases).

C.2.1.4. Conditions

The Conditions element contains conditions on the use of the assertion which should be checked by a service provider. The typical elements to check are shown in Table C-6.

<saml:Conditions

NotBefore="BEGIN VALIDITY TIME"

NotOnOrAfter="END VALIDITY TIME">

<saml:AudienceRestriction>

<saml:Audience>INTENDED RECIPIENT</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

Table C-6

SAML 2 Conditions Elements Useful for Troubleshooting

Element	Description
NotBefore	Start of validity period for assertion. This time should have passed when the assertion is received.
NotOnOrAfter	End of validity period for assertion. This time should not have already passed when the assertion is received.
Audience	Audience (intended recipient) of the assertion. May be specified in URN format. Used by a service provider to ensure it is the intended recipient of an assertion it receives.

C.2.1.5. Authentication Statement

The AuthnStatement element indicates when authentication occurred, and the AuthnContextClassRef can be used to return an indicator of the strength of the authentication mechanism used. This section of the response is not typically a frequent cause of issues. The typical elements to check are shown in Table C-7.

<saml:AuthnStatement

AuthnInstant="2019-01-19T19:11:28.407Z"

SessionIndex="SESSION INDEX">

<saml:AuthnContext>

<saml:AuthnContextClassRef>

urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified

</saml:AuthnContextClassRef>

</saml:AuthnContext>

</saml:AuthnStatement>

Table C-7

SAML 2 AuthnStatement Elements Useful for Troubleshooting

Element	Description
AuthnContextClassRef	If a particular AuthnContextClassRef was requested, this can be checked to see if it matches the requested value.

C.2.1.6. Attribute Statements

Attribute statements are used to convey additional user profile attributes about the user. A frequent cause of issues is a mismatch between attributes expected by an application and the attributes delivered in a SAML assertion. The specific attributes will vary across different applications and identity providers. We have shown two attributes in the following snippet, one for a user identifier and one for a user’s email address. The list of attribute statements in an assertion should be checked to ensure all attributes required by an application are delivered in the assertion.

<saml:AttributeStatement

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<saml:Attribute

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml:AttributeValue xsi:type="xs:string">

USER IDENTIFIER

</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute

Name=

"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml:AttributeValue xsi:type="xs:string">

USER EMAIL ADDRESS

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

</samlp:Response>

C.3. Validation

Applications must properly validate the SAML assertions they receive. We will focus in this section on validation steps for applications, as this book is targeted to application developers rather than identity provider implementers. We will further focus on validation steps that may impact troubleshooting as there are now many good SAML 2 libraries available to parse and validate protocol messages, and we do not recommend that new applications implement the SAML protocol or the validation of protocol messages themselves. We assume a simple scenario where an Identity Provider responds to a Service Provider without any intermediate proxies, transitive relationships, or further redirection to other parties.

Assuming that responses are sent to an application using HTTP-POST, validation steps include checking

The response contains a valid, properly formatted SAML 2 response.
The Destination element of the SAML response matches the Service Provider.
The Issuer of the response assertion matches the configured/expected Identity Provider.
The Status element indicates success and does not contain an error code.
The digital signature on an assertion is valid for the issuing identity provider.
The Subject element exists and contains the subject of the assertion, using a name format for the subject that is recognizable by the Service Provider.
The AudienceRestriction in the Conditions element matches the Service Provider.
The AuthnContext element of the AuthnStatement matches an application’s requirements, such as for the strength of the authentication mechanism used.
The AttributeStatements contain values for any attributes required by the application.
The application’s Assertion Consumer Service URL that received a response is the same as the Recipient in the SubjectConfirmationData element of the response received.
The NotOnOrAfter time specified in the SubjectConfirmationData and Conditions elements in the response has not passed. It is acceptable to allow a small tolerance for clock differences between servers, but if assertions repeatedly time out, the issue should be fixed by configuring servers to synchronize clocks with time servers.
The ID for each incoming assertion is not on a list of previously used assertion ID values, maintained by the application for the length of time the IDs would be valid (from NotOnOrAfter), to ensure that the assertion has not been replayed.

Additional validations only possible with SP-initiated flow include

Check that the InResponseTo element in the response matches the unique ID of the authentication request sent.
If a value was sent using the RelayState parameter, the response should contain the same value in the RelayState parameter.

Additional validations for IdP-initiated flow include

There should not be an InResponseTo element.

The RelayState element may include a URL at the Service Provider to which the user is to be directed after a successful authentication response is received. With an IdP-initiated flow, such use of RelayState is often undertaken with a mutual agreement between the Service Provider and the Identity Provider. If no RelayState is specified, a Service Provider should have a designated default URL to which a user will be redirected after a response is received. If RelayState is used, the contents must be protected against tampering with a mechanism that supports size restrictions for this field. It should be noted, however, that the protocol does not provide a way to ensure the integrity of a SAML message and RelayState pairing. In other words, an attacker could potentially recombine a SAML message from one response with a RelayState from another response. With IdP-initiated flows, especially with the use of RelayState, it may be difficult for a Service Provider to validate that a response is legitimate and hasn’t been tampered with, making IdP-initiated flows vulnerable to additional risks.

Our discussion in this section has assumed the use of general security measures such as the use of a suitably up-to-date version of TLS and secure cipher suite for the protocol communications, along with secure key management for cryptographic keys, and trusted certificate authorities for trusted bindings between public keys and identities.

Appendix D: Public Key Cryptography

This appendix provides a brief description of how public and private keys are used to encrypt and sign tokens in a public key cryptography scheme.

With public key cryptography, there is a private key and a public key. The private key is a long string of random characters. A public key is generated from the private key. The two keys are called a key pair. The owner of a key pair should keep the private key a secret, but the public key is designed to be distributed to others and used as described in the following.

To encrypt a message or object, the sender uses the public key of the intended recipient to encrypt the message. Once it is encrypted, only the recipient, who holds the matching private key, can decipher the message.

To digitally sign a message or object, the signer uses its private key to digitally sign the message. The recipient of the message uses the sender’s public key to verify the signature on the message.

Appendix E: Troubleshooting Tools

The following sections contain tools the authors have found useful for troubleshooting issues with applications using identity protocols.

E.1. Capture an HTTP Trace

An HTTP trace is essential for troubleshooting many scenarios. The following instructions indicate how to access trace features in different browsers, at the time of writing. A search for “How to capture an HTTP trace in <name of browser>” should provide current instructions if the following instructions no longer apply:

Chrome

Open Developer Tools.
Click the Network tab.
Check the “Preserve Log” option, if not already checked.
After capturing a trace, click the Export HAR arrow button to save the trace in a .har file.

Firefox

There is a nice extension called Live HTTP Headers that is handy with Firefox.
Alternatively, you can open a new tab in Firefox and select “Tools” ➤ “Browser Tools” ➤ “Web Developer Tools” and then click the Network tab.
Reproduce the issue.
Right-click in the trace window and select “Save All As HAR.”

Edge

Press F12 to bring up Developer Tools.
Click the Network tab. Make sure the “Preserve log” option is checked.
Reproduce the issue.
Click the Export HAR button.

Safari

In Safari Preferences, Advanced, turn on “Show Develop Menu in Menu bar.”
When viewing a site, use the Develop ➤ Show Web Inspector to view.
Click the Network tab.
Turn on Preserve Log. Reproduce the issue.
Use “Export” to save the HTTP trace to a .har file.

E.2. View a HAR File

If you can reproduce an authentication/authorization issue, you can view the HTTP trace of the issue in your own browser. However, if you need to view an HTTP Archive file captured by someone else, the following tools will be useful.

Caution

Remember that HTTP trace files may contain sensitive information such as passwords or security tokens. You should remove sensitive content such as passwords before sharing or uploading trace files, as well as reset credentials and revoke any tokens, as appropriate.

If the tools listed as follows are no longer available, you should be able to find new ones by searching for “HTTP Archive View” or “How to view a .har file.”

Chrome

The Chrome browser supports the ability to import a .har file.

Open the Chrome Developer Tools Network tab.
Drag and drop your .har file onto the tab.

Google .har file analyzer

Google provides a website which can be used to view HTTP Archive (.har) files:

https://toolbox.googleapps.com/apps/har_analyzer/

Fiddler

Fiddler, another useful network trace tool, can also be used to view .har files:

https://docs.telerik.com/fiddler/configure-fiddler/tasks/configurefiddler

E.3. Capture a Network Trace

To capture API traffic originating from a back-end application component or native application, you can rely on your favorite debugger or a network trace tool such as the following:

Fiddler

https://docs.telerik.com/fiddler

Charles Proxy

www.charlesproxy.com/

E.4. View Security Tokens

The ability to view security tokens issued by identity providers greatly aids the debugging process. Table E-1 contains some of our favorites.

E.5. Test APIs

A tool for testing API calls, without the added complexity of a client application, can aid debugging. Table E-2 contains tools we’ve found helpful for testing calls to APIs.

Table E-1

Useful Tools for Viewing Security Tokens

Tool	Purpose
https://jwt.io	Tool provided by Auth0 for viewing JWT tokens.
https://samltool.com	Tool provided by OneLogin for viewing SAML tokens.
https://samltool.io	Tool provided by Auth0 for viewing SAML tokens.

Table E-2

API Debugging Tools

Tool	Purpose
https://getpostman.com	Tool for learning, debugging, and testing API calls.
https://insomnia.rest/	Tool for learning, debugging, and testing API calls.

Appendix F: Privacy Legislation

This section contains information on privacy-related legislation. Countries around the world are recognizing the need to enact legislation to protect personal information. It is beyond the scope of this book to provide a comprehensive list of privacy legislation as the list is long and new legislation is being introduced on an ongoing basis. In fact, at the time of writing, the privacy legislation in several countries is undergoing significant revision, in some cases to align more closely with the GDPR.

We will provide selected resources for learning more about the primary privacy legislation applicable to the EU, namely, the GDPR, and legislation in the United States, which takes a sectoral approach to privacy legislation. We’ve also provided resources to help you find legislation applicable to other countries and to stay on top of privacy changes around the world.

The information provided in the following does not constitute legal guidance, and we recommend that organizations consult with legal and privacy professionals in the development of any privacy compliance efforts.

F.1. European Union

The European Union updated its 1996 Data Protection Directive with comprehensive privacy legislation known as the EU GDPR, General Data Protection Regulation.ⁱ The GDPR took effect in 2018 and applies to any entity that receives, stores, or processes data about persons in the EU and includes stiff fines for noncompliance.

Note that individual countries within the EU may enact additional country-specific legislation for implementation of the GDPR.

F.2. United States

In the United States, there are several privacy-related laws rather than one single federal privacy law. Privacy legislation in the United States uses a sectoral approach with different laws for different industry sectors and for several individual states:

GLBA (Gramm-Leach-Bliley Act)ⁱⁱ – Specifies privacy and security requirements for the financial industry governing the handling and protection of NPI (nonpublic personal information).
HIPAA (Health Insurance Portability and Accountability Act)ⁱⁱⁱ – Specifies privacy and security requirements for the healthcare industry, governing personal data as well as information about a person’s healthcare, health status, and payment for healthcare.
FTCA (Federal Trade Commission Act)^iv – Protects consumers against deceptive or unfair business practices, which may include uses of personal data that do not conform to published privacy notices. See in particular the FTC Privacy Rule.
FCRA (Fair Credit Reporting Act)^v and FACTA (Fair and Accurate Credit Transactions Act)^vi – Governs protection of personal data, including a person’s credit score, capacity for credit, and any personal characteristics related to credit worthiness. It also obligates financial institutions to implement measures to detect and respond to suspected instances of identity theft, via the Identity Theft Red Flags Rule.
CAN-SPAM (Controlling the Assault of Non-Solicited Pornography and Marketing)^vii – Governs the use of unsolicited commercial emails whose primary purpose is advertisement or promotion of commercial products or services.
TCPA (Telephone Consumer Protection Act)^viii – Governs telemarketing calls and the use of automated calls, otherwise known as robocalls.
COPPA (Children’s Online Privacy Protection Act)^ix – Governs the collection, use, and disclosure of information about children under the age of 13 for protection from unfair or deceptive practices. It places requirements on websites or online services targeted to children under 13 or which knowingly have personal data about children under 13.
VPPA (Video Privacy Protection Act)^x – Originally established in 1988 and amended in 2012, it governs the protection of personal data related to rental or sales of videos.

In addition, a patchwork of different privacy laws is being enacted by individual states in the absence of national legislation in the United States. Examples are

California Consumer Privacy Act (CCPA)^xi – California enacted the California Consumer Privacy Act (CCPA) which took effect in January 2020. The CCPA entitles California residents to know what personal data is being collected, whether it’s sold or shared, the right to opt out to the sale or sharing of their personal data, access to their data, and equal service and price even if they exercise their opt-out choice. The CCPA was the first comprehensive data privacy law enacted by a state in the United States.
California Privacy Rights Act (CPRA)^xii – This act takes effect on July 1, 2023, and expands upon the CCPA. It enlarges the definition of “personal information” to include things like cookies, browser history, IP addresses, geolocation data, and device identifiers. It defines a new category of data to be considered sensitive personal information, adds measures designed to prevent users’ geolocation from being tracked, adds further protections for minors, and provides greater legal rights for users, including private right of action such as the ability to sue providers after a data breach. The CPRA also establishes the California Privacy Protection Agency to serve as an advocate for users and to oversee and enforce privacy requirements.
Virginia Consumer Data Protection Act (CDPA)^xiii – The Virginia CDPA was signed on March 2, 2021, and becomes effective on January 1, 2023. It is the second comprehensive data privacy law at the state level in the United States and establishes several requirements similar to the GDPR and the CCPA. The CDPA requires organizations to provide privacy notices and disclose if personal data is sold or used for targeted advertising and provide an opt-out mechanism. It gives users the right to view, correct, and request the deletion of their personal data held and the right to opt out of certain processing of their data. The Virginia CDPA applies to individuals who conduct business in Virginia or target services to Virginia residents as well as meet thresholds related to the number of consumers whose personal data is processed and the percent of gross revenue gained from the sale of personal data.
Colorado Privacy Act (CPA)^xiv – The Colorado CPA was signed into law on July 7, 2021, and becomes effective on July 1, 2023. It is the third comprehensive, state-level data privacy legislation in the United States and contains elements similar to the GDPR, CCPA, CPRA, and the Virginia CDPA. It applies to data controllers who conduct business in Colorado or target services to Colorado residents and meet thresholds related to the number of consumers whose personal data is processed and whether any revenue or discounts are gained from the sale of personal data.
Vermont Data Broker Privacy Law^xv – Vermont has enacted legislation that applies to data brokers that collect, store, aggregate, and sell data about data subjects. This legislation applies to brokers who don’t have a direct relationship with the data subjects. The law requires data brokers to be transparent about their practices by registering with the state, secure the data they hold, and to not use personal data to harass or discriminate against data subjects. The Vermont law also requires free credit freezes to protect consumers whose identity has been stolen.

For information on other states, the International Association of Privacy Professionals has prepared a chart comparing US states’ passage of comprehensive privacy legislation.^xvi With individual states each passing their own different legislation, businesses will need to devote time to understanding how to be compliant with different states’ legislation in an efficient manner.

F.3. Other Countries

For information on privacy legislation in other countries, we have found the following sites useful for identifying privacy laws in each location and tracking news on privacy changes:

DLA Piper – Data Protection Laws of the World^xvii
United Nations Conference on Trade and Development – Data Protection and Privacy Legislation^xviii
International Association of Privacy Professionals (IAPP) – (Some content for members only)^xix

In reviewing privacy legislation, it is worth noting that in some countries, there is different legislation for private sector businesses vs. public sector entities, and there may be additional legislation enacted by regional governments or for specific industries. For example, in Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA)^xx applies to private sector businesses in Canada, whereas the Privacy Act^xxi applies to federally regulated public bodies in Canada. In addition, some Canadian provinces have enacted additional privacy legislation.

F.4. Notes

Appendix G: Security Compliance Frameworks

Security frameworks provide a list of controls that represent requirements that would reasonably be expected of an organization to adequately secure systems and information under its control. We list here some security frameworks we have had occasion to review, in two sections. The first section contains general security frameworks that are not specific to an individual country or government. The second section presents several security requirements or frameworks that are specific to the United States.

G.1. General Security Frameworks

The following is a list of security frameworks, in alphabetical order.

G.1.1. Center for Internet Security – Top 20 Controls

The CIS Controlsⁱ are a series of 20 foundational cybersecurity controls intended to eliminate the most common attacks.

G.1.2. Cloud Security Alliance

The Cloud Security Allianceⁱⁱ has a mission to promote best practices for security assurance for cloud providers. CSA has a three-level certification program called CSA STAR based on a published framework of security controls known as the Cloud Controls Matrix (CCM).

G.1.3. ISO 27000

ISO 27000ⁱⁱⁱ is a family of standards published by the ISO (International Organization for Standardization) for information security management systems. Figure G-1 shows the ISO/IEC 27000 family of requirements, guidelines, and standards.

Figure G-1
ISO/IEC 27000 ISMS Standards Family

Each of the standards/guidelines in the diagram may be purchased from ISO. A certified, independent auditor is required to verify compliance with the framework controls. After an audit of an organization’s evidence of compliance, a report is issued for the audit period stating if the controls were met. Organizations that pass the audit can place a certificate seal on their website.

G.1.4. PCI DSS

The PCI DSS (Payment Card Industry Data Security Standard)^iv was created by the payment card industry. Any vendor processing credit card data is expected to be compliant with the PCI DSS standard. It also applies to other systems that can impact the security of systems subject to PCI DSS.

G.2. US Frameworks

The following frameworks are applicable to the United States. They may be applicable to private sector organizations or applicable to government agencies and those doing business with them. Even if they are not mandatory for your project, a lot can be learned about best practices by studying the requirements, which may be useful in preparing for an audit or future requirements.

G.2.1. CJIS Security Policy^v – Criminal Justice Information Services Security Policy

In the United States, the Criminal Justice Information Services (CJIS) Security Policy governs the protections which must be provided for the handling of personal data related to criminal justice, including fingerprints and criminal background records.

G.2.2. FFIEC Information Technology Examination Handbook and Cybersecurity Assessment Tool^vi

The US Federal Financial Institutions Examination Council (FFIEC) unifies standards and principles and provides security guidance for financial institutions. The FFIEC has published the Information Technology Examination Handbook which consists of 11 booklets including one on Information Security. It has also published the Cybersecurity Assessment Tool which includes principles and standards in the Examination Handbook. The Cybersecurity Assessment Tool can be used as a self-assessment tool to prepare for an examination or audit.

G.2.3. FISMA – Federal Information Security Management Act^vii

FISMA requires each US federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other sources. The FISMA standards include NIST publications FIPS-199, FIPS-200, and the NIST 800 series.

G.2.4. FedRAMP – Federal Risk and Authorization Management Program^viii

FedRAMP defines a process for the evaluation, authorization, and monitoring of the security of cloud service providers used by US federal agencies. FedRAMP approval is required before a cloud service can be used by a federal agency (with a few very limited exceptions).

G.2.5. GLBA Safeguards Rule^ix

This portion of GLBA (Gramm-Leach-Bliley Act) requires financial institutions to have measures in place to protect personal data, including names, addresses, social security numbers, bank account, and credit card information, as well as credit and income history.

G.2.6. HIPAA^x

In the United States, the Health Insurance Portability and Accountability Act has a security component known as the HIPAA Security Rule. This rule establishes standards for the protection of electronic personal health information. This includes personal data related to healthcare, health status, and payment for healthcare.

G.2.7. HITECH Act^xi

In the United States, the HITECH (Health Information Technology for Economic and Clinical Health) Act governs the adoption of technology for managing electronic health records. Subtitle D of this act covers the security and privacy of electronic health information.

G.2.8. NIST^xii

The National Institute for Standards and Technology in the United States is a government body that publishes standards. The NIST cybersecurity framework is a voluntary framework of standards, guidelines, and best practices for cybersecurity. This framework references the NIST 800 series of publications which provide guidelines and technical specifications for cybersecurity.

G.3. SOC(Service Organization Control)

G.3.1. SOC1

A SOC1 report focuses on a service organization’s controls that are likely to be relevant to an audit of the entity’s financial statements. Control objectives are related to both business process and information technology. SOC1 reports follow the Statement on Standards for Attestation Engagements (SSAE) 18 standard.

G.3.2. SOC2

Service Organization Control 2 is a set of controls against which a company is audited, related to security, privacy, confidentiality, processing integrity, and/or availability. The specific set of controls for SOC2 is defined by each company. As the SOC2 assessment is not based on an open standard set of controls, information on the company-specific controls is included in the SOC2 report, prepared by an auditor, after a SOC2 compliance audit. The SOC2 report was created in part because of the rise of cloud computing and business outsourcing of functions to service organizations. These are called user entities in the SOC reports. Liability concerns have caused an increase in demand in assurance of confidentiality and privacy of information processed by companies and organizations.

G.4. Notes

Index

Access control list (ACL)

Access policy enforcement

Account requirements

account linking

delegation

impersonation

mergers and acquisitions

progressive profiling

Anti-Money Laundering (AML)

Apple Face ID

Apple Touch ID

Application Programming Interface (API)

authorizations

back-end API

client applications

custom claims

extensibility

front-end application

front-end functions

front ends

helper functions

introspection specification

JWT-formatted access

OAuth 2 scopes

OpenID Providers

processing request

tests

user authorization

Attribute-based access control (ABAC)

Authentication

biometric factors

deployments

identity provider request

knowledge-based authentication

MFA

OIDC

private cryptographic key

SAML 2

session timeouts

static passwords

step-down

step-up

stronger forms

Authorization

client applications

attributes

delivery

enforcement

OAuth 2 request

policy enforcement

application access

data access

functional access

user authorization

delivery

enforcement

profile attributes

transactional attributes

user vs. client application

Authorization code flow

Authorization code grant

Browser-based application

California Consumer Privacy Act (CCPA)

California Privacy Rights Act (CPRA)

Center for Internet Security (CIS)

Centralized user repository

Certificate of deletion

Client credentials grant

Client-Initiated Backchannel Communication (CIBA)

Cloud Controls Matrix (CCM)

Cloud Security Alliance (CSA)

Colorado Privacy Act (CPA)

Compliance

assessment and certification

competitive advantage

data protection

definition

efficiency

elective compliance frameworks

GDPR

industries

list of activities

privacy compliance

reduce penalties

security compliance

security/privacy standards

Confirmation notifications

Consent management

Criminal Justice Information Services (CJIS) Security Policy

Cross-Site Request Forgery (CSRF)

Cross-Site Scripting (CSS)

Delegation

Demonstrating Proof-of-Possession (DPoP)

Deprovisioning

account termination

certificate of deletion

data transfer

delete account

preserve account record

preserve identities

reprovision requirements

right to erasure

secure deletion

Device Authorization Grant

Document-writing app

code-sharing web sites

compliance requirements

features and services

frameworks

identity provider service

management requirements

access controls

anonymous document creation

API calls

provisioning options

sensitive data

session timeout

single sign-on

user logs out

users log in

web-based single-page application

platform

Environment requirements

identity provider discovery

multitenant applications

shared workstations

Exceptions

accounts

data restore

decommission

orphaned account

takeover

compromised security information

credentials

personal data

secrets

identity provider

account recovery requests

breached passwords

brute force attack

system outage

administrative access

authentications

provisioning process

External identity service

characteristics

customer types

factors

government-issued online identity

industry consortium

organization-controlled identity

organizations

self-registered identity

social provider accounts

Failures

cleartext passwords

encrypt sensitive data

insiders threat

MFA

pay attention to process

phishy emails

secure coding practices

security vulnerability

target’s HVAC

Fast Identity Online (FIDO)

Fast Identity Online v2 (FIDO2)

Federal Financial Institutions Examination Council (FFIEC)

Federal Information Security Management Act (FISMA)

Federal Risk and Authorization Management Program (FedRAMP)

Form_post response mode

Front-end functions

API calls

helper functions

logout

OpenID Connect

sessions

token management

tokens

user authentication

General Data Protection Regulation (GDPR)

Gramm-Leach-Bliley Act (GLBA)

Hashing algorithms

Health Information Technology for Economic and Clinical Health (HITECH)

Health Insurance Portability and Accountability Act (HIPAA)

HTTP Archive View (HAR file)

Chrome

Fiddler

Google

HTTP trace

Chrome

Edge

Firefox

Safari

Identifiers

Identities

access policy enforcement

account management and recovery

authentications

authorizations

autonomous vehicles

definitions

deprovisioning

events in life of

evolution of

IoT devices

logout

MFA

personal agents

provisioning

robots

sessions

SSO

step-up authentication

Identity and access management (IAM) System

Identity attributes

account recovery

advantages/disadvantages

credentials reset

enterprise provider

helpdesk reset

password guidance

SCIM protocol

social providers

user profile data

validations

Identity defederation

Identity management

centralized user repository

design questions

easier adoption

e-identity initiatives

federated identity and SAML 2

identity challenges

OAuth 2

OAuth 2.1

OIDC

OpenID protocol

per-application identity silo

sample application

smaller devices

SSO servers

standard protocols

stronger authentication

WS-Fed

Identity migration

Identity proofing

Identity Provider Initiated SSO

Identity provisioning

administrative account creation

automated account

cross-domain account

manual account

approaches

invite-only registration flow

leverage external identity service

migration

bulk migration

gradual migration approach

supporting legacy hashing algorithms

progressive profiling

self-registration

Impersonation

Implicit grant

Internet of Things (IoTs)

Invite-only registration

JWT-secured Authorization Request (JAR)

Knowledge-based authentication (KBA)

Know Your Customer (KYC)

Logout

applications

application sessions

authentication brokers

in designing

identity provider session

multilevel authentication

multiple user sessions

OAuth 2.0

OIDC

back-channel

front-channel

specifications

redirects

relying party client application

SAML 2

session termination

SSO

triggers

user sessions

Multi-factor authentication (MFA)

Mutual-TLS

National Institute of Standards and Technology (NIST)

Network trace tool

No email address

OAuth 2

access tokens

API calls

with authorization

authorization code grant

authorization requests

+ PKCE

responses

token endpoints

client credentials

client profiles

confidential clients

implicit grant

authorization request

URL hash fragment

overview

public clients

refresh token

refresh token rotation

resource owner password credentials

authorization requests

resource servers

roles

sender-constrained token

tokens and authorization code

OAuth 2.0

OAuth 2.1

One-time password (OTP)

OpenID Connect (OIDC) protocol

authentication

authorization code and tokens

authorization code flow

authentication request

authentication response

token requests

client types

endpoints

ID Tokens

implicit flow

authentication request

authentication response

parameters

roles

session management

UserInfo endpoint

OpenID Connect RP-Initiated Logout

OpenID protocol

P, Q

Payment Card Industry Data Security Standard (PCI DSS)

People requirements

family account

temporary accounts

Per-application identity silo

Privacy legislation

CCPA

CPA

CPRA

European Union

other countries

United States

VCDPA

Private keys

Progressive profiling

Proof Key for Code Exchange (PKCE)

Provisioning phase

Pushed Authorization Request (PAR)

Refresh token rotation

Refresh tokens

Resource owner client credentials grant

Response modes

Rich Authorization Request (RAR)

Role-based access control (RBAC)

SAML Profile for OAuth 2.0 Authorization Grants

Security Assertion Markup Language (SAML) 2.0 protocol

assertions

attribute statements

authentication brokers

authentication requests

authentication responses

AuthnStatement

conditions

configurations

digital signature

federated identity

identity federation

identity providers

IdP-initiated flow

overview

protocol binding

SAML assertions

SAML profile

service providers

SP-initiated flow

SSO

subjects

trust relationship

working principles

Security challenges

diversifying motives

evolving targets

ongoing breaches

Security frameworks

CIS controls

CJIS Security Policy

CSA

FedRAMP

FFIEC

FISMA

GLBA

HIPAA

HITECH

ISO 27000

NIST

PCI DSS

SOC

US Frameworks

Sender-constrained

Service Organization Control (SOC)

Service provider (SP)-initiated SSO

Sessions

application sessions

authentication brokers

continuous authentication

duration

identity providers

multiple sessions

relying parties

renewal

token renewal

SIM-swapping attack

Single sign-on (SSO)

authentication mechanisms

benefits

consumer-facing environments

definition

multiple identity providers

servers

session attributes

session duration

trade-offs

working principles

Soft delete

Status transitions

Step-up authentication

System for Cross-domain Identity Management (SCIM) protocol

Targets

cars

homes and businesses

medical implants and monitoring

perimeter protections

robots

Token endpoints

Tracking Protections

Troubleshooting

API calls

application issue

applications impact

authentication/authorization

capture HTTP traces

cross checking

environmental factors

HTTP status code

identity protocols

independent browser windows

intermittent problem

JWTs and SAML tokens

parameters in a request

problem replication

sequence of interaction

symptoms and issues

test environment

token contents

tools

trace of HTTP and API calls

users impacted

validation errors

view HTTP traces

Universal Second Factor (U2F)

User consents

UserInfo endpoint

User Managed Access (UMA)

View security tokens

Virginia Consumer Data Protection Act (VCDPA)

W, X, Y

WebAuthn

Web Services Federation Language (WS-Fed)

WriteAPaper application

Zero Trust

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Back Matter

Create new playlist

Sign In

Sign Up

Table of Contents for
Back Matter