---
title: SAML 2.0 profile for authorization
description: Use SAML 2.0 assertions to request access tokens in OAuth 2.0 authorization grants
component: pingam
version: 8
page_id: pingam:am-oauth2:oauth2-saml2-bearer-grant
canonical_url: https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-saml2-bearer-grant.html
llms_txt: https://docs.pingidentity.com/pingam/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: 2026-08-28T08:59:36Z
keywords: ["OAuth 2.0", "SAML 2.0", "Grant Flow", "Endpoints", "Setup & Configuration"]
page_aliases: ["oauth2-guide:oauth2-saml2-bearer-grant.adoc"]
superseded_by: https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-saml2-bearer-grant.html
section_ids:
  saml_assertion_for_authorization_flow: SAML assertion for authorization flow
  configuration_requirements: Configuration requirements
  example_access_token_request: Example access token request
---

# SAML 2.0 profile for authorization

* Endpoints

  * [/oauth2/access_token](oauth2-access_token-endpoint.html)

RFC 7522 [Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://www.rfc-editor.org/info/rfc7522) defines the use of SAML 2.0 assertions for requesting access tokens *and* for client authentication. This page describes how to exchange a SAML 2.0 assertion for an access token.

In this profile, the SAML 2.0 identity provider (IDP) authenticates the resource owner, obtains authorization, and prepares a signed assertion to use the PingAM REST APIs. PingAM does not interact with the resource owner in this grant flow or present consent pages.

## SAML assertion for authorization flow

![SAML 2.0 profile for authorization grant flow](_images/oauth2-saml2-bearer.svg)

1. The client directs the resource owner to the IDP for authentication.

2. The IDP authenticates the resource owner and returns a signed assertion.

3. On success, the IDP supplies a signed assertion.

4. The IDP redirects the resource owner to the client with the assertion.

5. The client exchanges the assertion for an access token.

6. PingAM validates the assertion and, on success, issues an access token to the client.

   If PingAM cannot validate the assertion, it returns an error.

7. The client uses the token when requesting access to protected resources.

8. The resource server contacts the authorization server to validate the access token.

9. The authorization server validates the token and responds to the resource server.

10. The resource server allows the client to access the protected resources.

## Configuration requirements

The OAuth 2.0 client application must:

* Inform the resource owner they grant consent by authenticating with the IDP.

* Consume the access token and handle errors as necessary.

* Include Grant Types: `SAML2` in its PingAM profile.

The IDP must:

* Issue signed assertions.

* Specify an issuer in the assertion matching the IDP's name; for example, `https://idp.example.com:8443/idp`.

* Specify an audience in the assertion matching the service provider's (SP) name; for example, `https://am.example.com:8443/am/`.

* Specify the resource owner with an identifier known to PingAM; otherwise, PingAM returns an error such as the following:

  ```
  {"error_description":"AM identity should not be null","error":"server_error"}
  ```

  When using a transient flow, configure an identity in the SP's Transient User setting to map all transient ID references to a specific identity.

The PingAM configuration must include:

* The OAuth 2.0 provider and SAML 2.0 SP in the same PingAM server.

* A requirement in the SP configuration for signed assertions from the IDP.

* A circle of trust with the IDP and the SP.

* Grant Types: `SAML2` in the OAuth 2.0 provider configuration. (This is the case by default.)

## Example access token request

```bash
$ curl \
--request POST \
--user 'myClient:mySecret' \
--data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer' \
--data 'assertion=<saml-assertion>' \
--data 'redirect_uri=https://www.example.com:443/callback' \
--data 'scope=openid' \
'https://am.example.com:8443/am/oauth2/realms/root/realms/alpha/access_token'
```

As shown in the example, the request includes these parameters:

* `grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer`

  Required for this grant.

* `assertion=<saml-assertion>`

  The Base64url-encoded SAML 2.0 assertion. Use Base64url encoding rather than standard Base64 encoding; Base64url replaces `+` and `/` with `-` and `_`. Submit the value as a form-encoded parameter.

* `scope=openid`

  Example scope. The `scope` parameter is required if no default scopes are set for the client.