SAS Viya 3.5 OpenID Connect Implicit Flow
I have seen a few customers trying to implement SAS Viya with an OpenID Connect provider using the Implicit Flow. In this article I want to explore what the Implicit Flow is compared to the Authorization Code flow. This should illustrate why the Implicit Flow is not practical or supported for authenticating to SAS Viya.
Authentication with OpenID Connect will result in the client, which in our case is SAS Logon Manager, receiving from the OpenID Connect provider an ID Token and Access Token. SAS Logon Manager uses the ID Token to identify the end-user and prove they have been authenticated by the OpenID Connect provider.
With SAS Viya we are only securing the "front door" with the third-party OpenID Connect provider. SAS Logon Manager will still create an internal ID Token used by the rest of the SAS Viya environment. The third-party ID Token is just used to authenticate to SAS Logon Manager.
The OpenID Connect specification defines three types of flow that can be used to obtain the ID Token. These flows are:
- Authorization Code Flow - the most commonly used flow, intended for traditional web apps as well as native / mobile apps. Involves an initial browser redirection to / from the OP for user authentication and consent, then a second back-channel request to retrieve the ID token. This flow offers optimal security, as tokens are not revealed to the browser and the client can also be authenticated.
- Implicit Flow - for browser (JavaScript) based apps that don't have a backend. The ID token is received directly with the redirection response from the OP. No back-channel request is required here.
- Hybrid Flow - rarely used, allows the application front-end and back-end to receive tokens separately from one another. Essentially a combination of the code and implicit flows.
The characteristics of these three flows is summarized here:
The flow used is determined by the response_type value contained in the Authorization Request sent by SAS Logon Manager to the third-part OpenID Connect provider. The table below shows how the response_type selects the type of flow:
Starting with SAS Viya 3.5 the sas.logon.oauth.providers.external_oauth set of configuration includes the responseType setting. The description shown in SAS Environment Manager for responseType is "The expected response type, either 'code' or 'token'.". So, within the SAS Environment Manager settings you can define the type of flow to be used.
What is the Authorization Code Flow
As we’ve stated above the Authorization Code flow is the most common flow for traditional web applications like SAS Logon Manager. This means a web application where there is a back-end server process. There are two steps to the Authorization code flow as summarized in the following table:
In step 1 SAS Logon Manager builds the Authorization Request and through a browser redirect sends the end-user to the authorization endpoint of the third-party OpenID Connect provider with the Authorization Request. The third-party authenticates the end-user, if they are not already logged in, and may request user consent to sharing information, as shown here with Google:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
The third-party then redirects the end-user’s browser back to SAS Logon Manager, at the URI included in the Authorization Request, including the Authorization code. With SAS Viya this URI is https://<sasviya_hostname>/SASLogon/login/callback/external_oauth, which will also have been registered with the third-party when SAS Logon Manager is registered as a client. The URI in the Authorization Request is normally also validated against the client registration before the end-user is authenticated.
Once SAS Logon Manager has the Authorization code it goes through step 2. SAS Logon Manager directly submits a request to the token endpoint of the third-party OpenID Connect provider. As part of this request SAS Logon Manager can authenticate itself as a client. This authentication can either be through a BASIC authenticate header, or starting with SAS Viya 3.5, with the client-credentials submitted in the body of the request. The configuration option clientAuthInBody under sas.logon.oauth.providers.external_oauth controls how this client authentication to the token endpoint occurs.
The third-party OpenID Connect provider, if the client-authentication is successful, and the Authorization code has not expired will respond with the tokens. The tokens sent back to SAS Logon Manager will be the ID Token, Access Token, and possibly a Refresh Token. SAS Logon Manager is then able to validate the ID Token and extract the end-user information from the ID Token. This authenticates the end-user to SAS Logon Manager.
What is the Implicit Flow
The Implicit flow is different to the Authorization Code flow in that all communication runs through the end-user’s browser. There is no second step where the client directly communicates with the OpenID Connect provider. This means there is no direct communication between SAS Logon Manager and the third-party OpenID Connect provider.
SAS Logon Manager, as before, builds the Authorization request and through the browser redirect send the end-user and the Authorization request to the third-part OpenID Connect provider. The provider, if necessary, authenticates the end-user and possibly asks for consent, just as before. However, in the Implicit flow the ID Token and Access Token are directly returned by the authorization endpoint.
The tokens are, in most cases, included in a URL fragment appended to the redirect back to SAS Logon Manager. This means the URI the end-user is redirected to is https://<sasviya_hostname>/SASLogon/login/callback/external_oauth#<ID TOKEN>\&<ACCESS TOKEN>. Notice this is a fragment so the separator is # rather than a query string which would use ?. The expectation with the Implicit flow is that JavaScript in the redirect page would then cause the end-user’s browser to parse the encoded tokens and pass them onto the client’s processing logic.
Why the Implicit Flow should not be used
To start with the current "OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-13" states the following:
In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or any other response type issuing access tokens in the authorization response, such as "token id_token" and "code token id_token", unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented. A sender-constrained access token scopes the applicability of an access token to a certain sender. This sender is obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g., a resource server). Clients SHOULD instead use the response type "code" (aka authorization code grant type) as specified in Section 3.1.1 or any other response type that causes the authorization server to issue access tokens in the token response. This allows the authorization server to detect replay attempts and generally reduces the attack surface since access tokens are not exposed in URLs. It also allows the authorization server to sender-constrain the issued tokens.
Since OpenID Connect is an extension to OAuth 2.0 we should take the same considerations for OpenID Connect as well. This means the recommendation is to avoid using the Implicit flow since the tokens in the authorization response are vulnerable to token leakage and token replay attacks. Instead applications should be using the Authorization Code flow.
Additionally, with SAS Viya SAS Logon Manager does not contain any JavaScript on the https://<sasviya_hostname>/SASLogon/login/callback/external_oauth endpoint to process the URL fragments that the Implicit flow most often returns. This means that when SAS Logon Manager receives a URL fragment it just returns a 500 error page.
For this error page the URL in the browser will contain "…#…\&…\&id_token=…\&access_token=…". Which illustrates that SAS Logon Manager is unable to process the token response generated by the Implicit flow. Finally, the log for SAS Logon Manager will contain a spurious error message like the following:
2020-03-30 11:26:40.151 ERROR 20975 --- [1-auto-1-exec-6] hainPostProcessor$HttpsEnforcementFilter : service [a2ad1e0bed78bff4] Uncaught Exception:
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.thymeleaf.exceptions.TemplateInputException: An
error happened during template parsing (template: "class path resource [templates/web/sas/login_implicit.html]")
This error can be ignored – the cause of the issue is that as per security guidance SAS Logon Manager does not support the Implicit flow.
Conclusion
The different flows provided by OpenID Connect can be confusing for both customers and SAS implementation teams. The information presented here hopefully makes it clear that only the Authorization Code flow should be used with OpenID Connect.
