Assertion Usage
Last updated
Last updated
For a limited set of situations involving offline transfer of authentication data we support using Assertions backed by an authorization Grant policy to obtain access tokens. An assertion must be obtained from Fanatics ID and cannot be created externally.
Currently this feature is only available for FanCash redemption and the Assertion can be obtained by scanning a QR code shown by a user.
To direct the user to the proper page, use the following deeplink template:
The redirect_uri will not be honored in this scenario but it must match the scheme and host of a redirect_uri registered with the OAuth2 client.
The QR code will contain a JSON object with the following structure:
The balance value represents a hint to the users FanCash balance. The caller should lookup the current balance to verify.
The assertion should be provided as-is to the token exchange endpoint.
The assertion obtained through the QR Code must be exchanged for a user access token to use with loyalty APIs. The token exchange may be performed through either the UI or Native API services.
For the token exchange you will send the following fields.
grant_type
jwt_bearer
assertion
The string encoded JWT Bearer Assertion provided by Fanatics ID.
client_id
The client_id assigned to your OAuth2 Client.
client_secret
This is your client secret that was generated when the client was configured.
redirect_uri
A redirect URI registered with the OAuth2 client, must match exactly.
scope
A space delimited list of scopes requested for the token to access. For this use case the scopes are controlled by the underlying grant policy associated with the campaign ID. This value is OPTIONAL for the `jwt_bearer` grant type.
access_token
This token can be used to call any of our APIs that you have the right permissions and scopes to call.
expires_in
The number of seconds the access token is good for.
id_token
refresh_token
token_type
Bearer
This endpoint conforms to . Please be aware that the body is sent form encoded with the content type application/x-www-form-urlencoded.
A JWT that contains information about the user. Please see for more information.
A refresh token that can be used for generating a new access token after the current one expires. This will only be returned if the Grant Policy allows it. If no refresh token is available, a new token exchange can be used to obtain a new access_token until the policy expires. See for more information.
Token Endpoint as described in https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint. A user access token can be passed as a scope to associate the account to create user specific, 'client_credentials', server tokens as described in https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.
Your OAuth2 client id
Your OAuth2 client secret
The OAuth code used for retrieving a bearer token
Grant type
Any session ids you want us to persist on the session
Any session ids you want us to persist on the session
The OAuth2 redirect URI
The OAuth refresh token.
A space separated list of scopes. To extend a user token for a token with broader scopes the original access token should be before the scope list followed by a space.
The JWT assertion to exchange for an access token when grant_type is jwt_bearer.
Access tokens must be treated as extremely sensitive. They should be stored securely on your server and should never be sent anywhere except our services. Do not send them back to end user clients or return them in a response from your servers.