Forum Discussion

jinzhong he's avatar
jinzhong he
Copper Contributor
Nov 07, 2021

Third party oidc authentication with SPSE failed

Following the new https://docs.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/oidc-1-0-authentication , I managed configuring oidc authenticate in SPSE with ADFS.  I then tried third ...
SharePoint Server Subscription
jinzhong he's avatar
jinzhong he
Copper Contributor
Mar 21, 2022
The client scopes were the default(emial, profile, etc), The IdentifierClaim I used on the sharepoint side was the UPN, and on the keycloak side, I mapped username to upn.
benjamin8733's avatar
benjamin8733
Copper Contributor
Mar 22, 2022

jinzhong he

 

Thanks so much jinzhong he! Knowing you got it working helped me get to the bottom of our issue.

 

On our keycloak instances (latest 17.0.0 quarkus version), in a new test realm, the default for "Access Token Lifespan" is set to 5 minutes. (For reference, on ADFS, this same value defaults to 60 minutes).

 

This is all fine usually, as many apps, (excluding sharepoint), we've tested on both keycloak and adfs work fine with either IdP with default timeouts.

 

But sharepoint has an odd behavior, in that by default: "when there are less than 10 minutes left in the lifetime SharePoint considers it expired"  (quote from https://sharepoint.stackexchange.com/users/3338/infotekka at https://sharepoint.stackexchange.com/questions/79864/sharepoint-2013-adfs-login-local-token-cache-always-expired ) 

 

The ULS logs confirmed the issue after sso login: "Found matching token cache entry but it's token is expired."

 

So sharepoint was rejecting the token as expired immediately after the successful SSO login from keycloak had completed. Adjusting the keycloak realm settings for "Access Token Lifespan" to 60 minutes up from the default 5 minutes fixed our issue. Login to sharepoint is now working correctly against keycloak.

Resources