Creating an OAuth Application: Vendor Workflow

As of July 12, 2021, this "Learn Veracross" site has been deprecated.  It will remain live through December 2022, but will no longer be updated. All knowledge content has moved to the new Veracross Community.  Please update your bookmarks.

Here is the new version of this article in the Veracross Community.


Because OAuth is a standard approach for enabling SSO, there is a lot of material on the internet about how to set up an integration with an OAuth provider.

In most cases we expect that vendors will use OAuth libraries (typically available publicly, not provided by Veracross) to integrate with an OAuth provider. However, to get a picture of how it all works, the basic HTTP request/responses are listed below. 

  • The authorization base url is “[school route]”.
  • The necessary OAuth grant type is “authorization code”.
  • Authorization Codes expire after 10 minutes and must be exchanged for Access Tokens as described below. When an Access Token is provided, it will include information about when it expires.


  1. When it’s time for a user to go to a vendor site, if they’re not already logged in they need to visit our authorization url. Authorization URLs are formatted like so:
    Request:[school route]/oauth/authorize
    ?client_id=[from OAuth Application]
    &redirect_uri=[encoded version of one of the pre-registered Redirect URIs from the OAuth Application]
    Note: the authorization url must include scope=sso in order for Single Sign On to work. Additionally, the `sso` scope is required to make the call to the userinfo endpoint below.
  2. If the user isn’t logged in to Veracross yet, they’ll have the opportunity to do so. After they log in (or if they were already logged in), the user will then be redirected to the Redirect URI, with an authorization code. For example:
    Redirect:[some string of digits]
  3. Vendors need to exchange the authorization code for an access token. This is done with a POST request to the authorization server, for example:
    Request:[school route]/oauth/token
    ?client_id=[from OAuth Application]
    &redirect_uri=[encoded version of one of the pre-registered Redirect URIs from the OAuth Application]
    &client_secret=[from OAuth Application]
    &code=[from the redirect]
    Response: This will be JSON that includes the access token 
  4. The access token is used to retrieve info about the user that has logged in, such as their Veracross account ID and username. This is done with a GET request to the authorization server, following this format:
    Request:[school route]/oauth/userinfo
    Request Headers: Authorization: Bearer [the user's access token]
    Reponse: This will be JSON that includes a "sub" (subject) field and "preferred_username"
    Note: sub is the internal account id, and uniquely identifies a user at a school. It must be combined with the school route to become globally unique. For example, different users at different schools might have the same sub value. Also note that schools may configure their own format for preferred_username, so it should only be used for display purposes (eg, some schools use email, some schools use other id's, etc)
  5. The user is now logged in to the vendor’s website, and can continue their activity there.