Managing Token Based Authentication

The expiry lifetime of the campusM auth token is 30 days by default. (This is configurable.) This determines how often the user needs to re-authenticate to use the campusM app. This may be set differently for Web and native/mobile, if necessary.

The campusM authorization token is different from the browser-cookie stored token used by the IdP system for single sign on to other systems and should not be confused. Typically, the IdP expiration is configured to be much shorter (a few hours or days) than the campusM-specific auth token.

campusM users can access external systems with a product integration or a link-out with single-sign-on functionality. This requires that the IdP token cached on the user’s browser is not expired. (The expiration of this token is set by the University’s IdP administrator). When expired, the user may need to re-authenticate to access specific external systems.

Some integrations require an additional unique trusted handshake between systems whereby a special third-party application token may be generated upon the user’s first access and then cached locally for that user and used securely for subsequent access from that device.

Since the campusM auth token itself is never used outside of campusM, it is not used for interfacing with external systems. However, since the campusM auth token may store optional attributes mapped from the IdP, those details can be retrieved for use in communications such as API calls with other external systems with which campusM interfaces. Such mappings can be useful for scenarios where that information is needed to communicate with other systems. For instance, a library integration may identify an end user by a different username than the username in campusM. With attribute mapping, if the IdP passes the additional attribute then it can be retrieved and used when communicating with the library system’s API, even though the username in campusM is different.

For OAuth2/OIDC there is also an option to use the access token returned during the login process to store optional attributes. Though similarly to IdP sessions, the campusM token lifetime is not tied to the expiration of the OAuth access token, but it can be configured to equal it. In cases where refresh tokens and expiration times are supplied along with access tokens, the refresh tokens can be used to automatically refresh the access tokens when needed. Note that these tokens are kept encrypted on the campusM token and therefore, it is recommended to keep these tokens limited to a reasonable size since they are sent with each request.