How to handle refresh tokens? (and sync with 3rd party IdP)

[emusgrave]

If using Jackson for a SPA, my expectation would be that it would allow for offline_access to be set and then issue refresh tokens.

Based on the code it does not seem that refresh tokens are supported. Is this an oversight or a purposeful omission since it would create a hole whereby the Jackson client could keep refreshing an access token even when the 3rd Party IdP has revoked that users access?

The only mention I can find in this repo of refresh tokens is in #280, and even though that is closed it doesn't seem like the refresh was implemented.

[deepakprabhakara]

Hi @emusgrave, we intentionally do not issue any sort of refresh tokens since the SAML protocol doesn't allow for any sort of revocation like OIDC does. Moreover authentication should be de-coupled from API access in general and we are not a good fit for OAuth or OIDC based API access. Directory Sync is an alternative to provision and de-provision users.

I'd be happy to discuss your specific use case and see if this sort of feature makes sense.

[emusgrave]

Jackson generates and returns an access token as the last step of the auth code flow here. There is no refresh token handling whatsoever, nor is offline_access referenced in the code.

But that's beside the point of my request for clarification of your previous statement. If you are saying that Jackson is not a good fit for OAuth based API access, then what is the goal of your solution? Is it meant just for authentication and relaying the ID Tokens? If so, that makes sense that you aren't putting much into the OAuth2 token(s) side of the protocol.

However the original question would still remain... Once a user authenticates once, how do you authorize their access from there? This comment is in the code for the ID Token expiration:
.setExpirationTime(${this.opts.db.ttl}s) // identity token only really needs to be valid long enough for it to be verified by the client application.
Does this basically mean you are assuming that once the user "logs in", they have access to the application forever? Because without some other server side session or other required server request, they'll never be forced to "log out" based on the expiration of the id token.
If I'm misunderstanding something please help me out. 🙏

[deepakprabhakara]

@emusgrave No worries at all, I hope the following will clarify things:-

• We only support Enterprise SSO providers (on the back of SAML and OIDC protocols) with the primary intention of authentication.
• We happen to use OAuth2.0 as a wrapper to abstract away the hard parts of SAML.
• We are not a good fit as a generic OAuth2.0 server/proxy. We are a pure proxy and can convert and speak OAuth2.0/OIDC/SAML on both sides of the proxy.
• Our own tokens are short lived because our responsibility is to let the app know who has logged in successfully and from there on your app decides how it wants to login the user. We do not support any means to refresh or revalidate the token after login. SAML protocol for example provides no way to revoke access.
• We however do fully intend to give you the access token and refresh token from the Identity Provider (My colleague will confirm this) but the lifecycle management of those tokens will have to be managed by you.

[niwsa]

@emusgrave @deepakprabhakara At the moment, the tokenSet returned from the 3rd party IdP is opaque and is not returned in the raw claims. It is only used to get user profile from the IdP's userinfo endpoint.

[deepakprabhakara]

@emusgrave We can pass through the access token and refresh token during profile exchange if that would be of use.

[emusgrave]

Thank you for the responses! I'm still on the learning curve and my org has not decided our exact requirements yet. I'll keep your solution in mind and come back around if I have more questions.