By default, SAS Logon Manager uses a registered client_id and client_secret to authenticate itself to your OKTA organization. SAS Logon Manager must authenticate to exchange the Authorization Code for an ID Token when using OpenID Connect authentication with OKTA. OKTA refers to this as client_secret_basic in their documentation. With SAS Viya 2024.01 SAS Viya now also supports the use of private_key_jwt for the authentication of SAS Logon Manager to OKTA. In this post we’ll look at why you might want to use private_key_jwt and how you can configure this.
The OKTA developer documentation states:
private_key_jwt: Use this when you want maximum security. This method is more complex and requires a server, so it can't be used with public clients.
Private Key JWT is a method of client authentication where the client creates and signs a JWT using its own private key. This method is described in a combination of RFC 7521 (Assertion Framework) and RFC 7523 (JWT Profile for Client Authentication), and referenced by OpenID Connect and FAPI 2.0 Security Profile.
Using private_key_jwt means that no secret is shared between SAS Logon Manager and OKTA. The private_key_jwt mechanism is based on asymmetric cryptography rather than symmetric cryptography which offers stronger algorithms. Also, the use of private_key_jwt is a requirement for the Open Banking APIs under the Financial Grade API (FAPI).
So, we can see you might want to move to using private_key_jwt instead of client_secret; either because of regulatory requirements, or generally because you want to improve the security of the OIDC implementation you are using.
The SAS documentation covers the steps to configure JWT Client Authentication with OKTA. You will need to complete steps in both SAS Viya and your OKTA tenant.
SAS Viya 2024.01 introduces an update to the sas.logon.oauth.providers configuration. This update is the addition of the property jwtclientAuthentication. The jwtclientAuthentication property has the description: "Use OIDC private key JSON web tokens (JWTs) for client authentication. The public key must be registered with the provider. Only effective if relyingPartySecret is not set." This is a Boolean property so can either be turned on or turned off, the default value is false or turned off.
Therefore, if we want to use private_key_jwt with OKTA we must change both jwtclientAuthentication and relyingPartySecret. The property jwtclientAuthentication must be turned on or set to true. At the same time the value of relyingPartySecret must be removed or set to the empty string. Then we need to consider how to register the public key with OKTA.
SAS Logon Manager automatically generates a public/private key pair that is used to sign the JSON Web Tokens that are provided to the SAS Viya web applications and other clients of SAS Logon Manager. The public key is then made available to consumers by SAS Logon Manager at its jwks_uri endpoint. You can find the URI by examining the OpenID Connect information published by SAS Logon Manager at the URL: https:///SASLogon/.well-known/openid-configuration. The jwks_uri should have the form: https:///SASLogon/token_keys. If you open this URI in a browser, you should see something like the following:
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "legacy-token-key",
"alg": "RS256",
"value": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMI...\n-----END PUBLIC KEY-----",
"n": "u3SsR7nTv...TTw"
}
]
}
By default, SAS Logon Manager will provide the single public key associated with the private key that it is using to sign JSON Web Tokens. In the JSON output from the jwks_uri everything between the second set of curly braces is the public key definition. In our example above that is from line 3 to line 11.
Once SAS Logon Manager is configured and you have retrieved the public key information you can configure OKTA. As per the SAS documentation you need to:
Remember, the public key is the entire information inside the keys object in the JSON output from the SAS Logon Manager jwks_uri. For our example this is:
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "legacy-token-key",
"alg": "RS256",
"value": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMI...\n-----END PUBLIC KEY-----",
"n": "u3SsR7nTv...TTw"
}
You’ll be able to see that OKTA has processes the contents correctly since it will be able to pick-up the Key ID "legacy-token-key" and this will be displayed as the KID attribute in the OKTA Administration Console. Also, the created date should reflect the date when you saved the configuration. This should look like the following:
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 introduction of support for using private_key_jwt as the client authentication mechanism for OpenID Connect configuration strengthens the security of the OIDC configuration. It also allows for support of the Open Banking APIs under the Financial Grade API (FAPI). With SAS Viya 2024.01 Stable release support for private_key_jwt is introduced with OKTA; the 2024.03 release will introduce support with Microsoft Entra ID.
If you want to explore this topic in more detail, you can refer to Course: Advanced Topics in Authentication on SAS Viya.
Find more articles from SAS Global Enablement and Learning here.
Join us for SAS Innovate 2025, our biggest and most exciting global event of the year, in Orlando, FL, from May 6-9. Sign up by March 14 for just $795.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.