Authorization
Last updated
Last updated
Our website follows the spec. Your application simply needs to send the user to the Fanatics ID SSO website with some important url parameters (defined below). Then when the user is done registering or logging in Fanatics ID will perform a redirect back to a uri that you provide at the beginning. That redirect will contain a code
that can be exchanged server side for an access token as part of the .
/oauth2/auth
To have the user authenticate in our SSO and authorize your app the following URL parameters are supported. For more details please see the OAuth 2.0 . You will need to URL encode all values.
scope
yes
A space-delimited list of permissions that the application requires.
openid
response_type
yes
Tells the authorization server which grant to execute.
code
client_id
yes
The client ID of the application that asks for authorization.
This will come from your client setup.
redirect_uri
yes
Holds a URL. A successful response from this endpoint results in a redirect to this URL. Please note that this redirect URI must be registered with your client id.
You will provide this as part of your client setup.
nonce
no
You will generate this.
state
no
You will generate this.
After the user is done on Fanatics ID we will perform a redirect back to the redirect_uri
that you provided.
code
yes
We will generate this.
state
no
The optional opaque value provided on the request.
You will generate this.
Please be aware that for security reasons our SSO must load in a full browser window or tab. There are security vulnerabilities with authentication in nested browsing contexts such as iframe & embed. Attempting to load our SSO in anything other than a full browser tab is not supported.
See for detailed information.
While not required per spec it is strongly encouraged! String value used to associate a Client session with an ID Token, and to mitigate replay attacks. For more details including how you should use it, see the OpenID .
While not required per spec it is strongly encouraged! An opaque value. If this request parameter is set in the request, then it is returned to the application as part of the redirect_uri. This is used to prevent cross-site request forgery exploits. For details on how you should use this, see .
OAuth 2.0 code that can be exchanged server side for an access token as part of the