There may be cases in which you want to redirect users to different login destinations based on the application they are trying to access. There are several ways that you can go about doing this and they vary in their implementation complexity and functionality.
Creating Multiple Edlink Applications
A straightforward (but maybe impractical) way to handle multiple login destinations is to create multiple Edlink applications. Each application will have its own application ID and secret, and you can specify a different redirect URI for each application. This way, you can mux the incoming requests to the correct application based on the redirect URI.
This may have some shortcomings, such as:
- The district admin will need to go through the Edlink onboarding for each application that the district utilizes.
- You will need to manage multiple application IDs and secrets.
- You will likely need multiple Clever or Classlink application configurations.
Utilizing OIDC Authentication
Edlink's OIDC implementation allows you to specify a login initiation URI, as defined in the OIDC specification. It is possible to use this opportunity to prompt the user to select the application they are trying to access. This can be done by creating a simple web page that lists the applications and redirects the user to the Edlink SSO endpoint with the appropriate redirect_uri (and the login_hint that is passed to you as a query parameter in the initiation GET request).
Utilizing the OAuth 2.0 State Parameter
When you initiate an OAuth 2.0 flow, you can pass a state parameter to the authorization endpoint. This parameter is then passed back to your application in the redirect URI. This can be used to mux the incoming requests to the correct application. The challenge with this method is that it does not work for SSO launches.
Launch Muxing
In many cases (such as LTI launches and Clever logins), the SSO provider initiates the sign on process. Given Edlink's OAuth 2.0 implementation, there is no opportunity to pass a state parameter or a redirect_uri to the authorization endpoint. Edlink will always redirect the user to the primary (i.e. first) redirect URI specified in the application settings and there will never be a state (more about launches).
This can be tricky if you have multiple applications that are all handling SSO through one Edlink application ID. In this case, you will need to implement a method of muxing the incoming requests to the correct application. Roughly speaking, here's how the process goes:
- Receive an incoming OAuth request from Edlink.
- Exchange the authorization code for an access token.
- Use the access token to make a request to the Edlink API to get the user's information or integration.
- Use the user's information or integration to determine which application the user is trying to access and direct them accordingly.
There is an example implementation in Node.js available on our GitHub page.