If you need to grant your customers with access to Crunch resources, without them having a stand-alone Crunch account, you may wish to instead create a redirect service that will log them in and then redirect them to specific Crunch pages. This way, each user has a Crunch account, fully managed by you, but they won't need to know the credentials nor will they have to enter credentials to log into Crunch. This system has certain limitations, outlined below, and is therefore useful only if a full OAuth provider is not available to do Single Sign On (SSO).
The One Time Redirect Authentication system is implemented by creating a redirect proxy service that:
- accepts user requests for Crunch resources and looks up user credentials,
- executes a server-to-server authorization request to retrieve a one-time password or token, and
- then redirects the user to a special Crunch endpoint with that token.
Then when visiting Crunch, the service:
- accepts requests on the special endpoint and authenticates the token,
- creates a full browser session for the user, and
- redirects the user's browser to the final location as requested
This can be better described through the following Sequence Diagram:
For example, Example Company has developed Example Application, and directs users to Crunch to further analyze the underlying dataset. The user clicks a link in the Example Application, which is handled by the redirect service, and then after a server-to-server exchange, redirects the user to Crunch with a One-Time Password to ensure the user is logged in; Crunch validates the token and then redirects the user to the Dataset Analysis page.
OAuth vs. One-time Passwords
The following are some considerations to keep in mind when considering either OAuth or one-time passwords.
Which approach is right for you?
- OAuth is more secure, an industry-standard, and is more easily outsourced to third-party vendors (e.g., Auth0, Okta) and even Open Source micro-services (IBM Liberty, Gluu, and many others).
- OAuth has sample code and open-source server plugins to common Java Identity providers (e.g., MITRe and Shibboleth).
- Both approaches require changes to your website/portal/application:
- Both systems need to create users inside the Crunch Application when they are granted access to data.
- Permissions to data need to be set up in Crunch before any datasets are visible to users.
How do I become an OAuth provider?
- If you don't implement an out-of-the-box solution, you'll need 3–4 API endpoints to authenticate the user to Crunch:
- Endpoints are standardized and have example code that is free to use.
- Usually, there’s a permission grant verification when users click over to a new OAuth consumer site, but because of Crunch's contractual relationship, it can be considered a “First Party” and won't need to implement that. Approval can be granted through non-technical means as well (EULA agreement, for example).
- No changes to your User Model objects are required.
- Small changes to sessions are needed to store temporary handshake tokens during the negotiation and to store OAuth tokens.
- Links to crunch are very similar to the ones used for one-time passwords, but instead of a token to keep secure, they will contain only the user's email address which doesn’t have the same security concerns as a password.
Benefits of OAuth over One-time Passwords
- The partner does not need to store any Crunch passwords.
- Users don't have a separate Crunch password to remember, change, or to become out of sync.
- No Crunch user assumptions are broken.
- It works even if the user already has an account with Crunch. Existing Crunch users can easily be changed to use your OAuth provider.