The Custom OAuth2 provider enables you to connect AuthRocket to a variety of external OAuth2 servers.
Any compliant OpenID Connect server implementation should work, as will many other OAuth2 servers.
However, due to the variety of OAuth2 implementations, not every server may work. If you have trouble, contact us.
If inactive, disables authentication using this provider.
A descriptive name for this provider. If using LoginRocket, will also be used as the title of the matching login button.
The app Client ID assigned by the server. It may have a slightly different name.
The app Client Secret assigned by the server. It may have a slightly different name.
The URL at the server which it initiates authorization. In app documentation that describes the OAuth2 flow, this is often the first listed URL and often ends with something like /auth or /oauth/authorize.
If the server requires that response_type is specified, include it in this URL:
https://example.com/oauth2/authorize?response_type=code
The URL at the server where a auth code is exchanged for an access_token. In OAuth2 flow documentation, this is often the second listed URL and often ends with something like /token or /oauth/access_token.
The scopes to request at the time of authentication. You must include whatever scopes are necessary to access the user’s email address as well as their profile in general. For OpenID Connect compatible servers, this will be openid email profile.
Scopes are separated by spaces. If the provider requires them to be separated by commas, then combine them together like this: scope_one,scope_two.
Additional scopes beyond this may be added as well. Best practices suggest requesting additional scopes just-in-time, instead of upfront. Requesting too many permissions initially may discourage users from signing up for your app to begin with.
AuthRocket must be given instruction about how to parse the data returned as the profile. Sometimes the profile is called User Info or similar. Data is always expected to be returned as JSON.
Some profiles used nested JSON structures. AuthRocket can parse these up to the 3rd level by using periods in the field name. For example, use the email field user.contact.email to discover the email from this JSON:
{"user": {"contact": {"email": "billy@example.com"}}}
The default field names correspond with OpenID Connect defaults. If the profile does not include a particular field, leave it blank on this page.
The URL at the server where the user info or profile can be retrieved. Some providers list this with the OAuth2 documentation and others list it in a separate place, so you may have to hunt for it. Sometimes it’s described as part of a graph API (especially at social network providers). In this case, it may end with /me.
The unique ID of the user.
The email address of the user.
A field indicating the user’s email address has been verified. If a field just confirms that the account has been verified by any means (and not necessarily email), we discourage using that field.
In the profile, when this field has a value of 1, true, or yes, it automatically marks the user’s email as verified.
The user’s first or given name.
The user’s last or family name.
The user’s full name. When first or last name are not available, the full name is attempted to be parsed sanely. Use first and last name when possible.
Questions? Find a Typo? Get in touch.