search

okta / okta-oidc-android

OIDC SDK for Android
https://github.com/okta/okta-oidc-android
Other
60 stars 45 forks source link

Feature request: Configurable token issued at time threshold in SDK #256

Closed thereallukesimpson closed 2 years ago

thereallukesimpson commented 2 years ago

Hi. We have a signifcant amount of users that set their device time forward or back more than 10 minutes from "real" time and hence get the following error when loggin in: AuthorizationException: {"type":6,"code":6007,"errorDescription":"Issued at time is more than 10 minutes before or after the current time"}

A few months ago I discussed with @FeiChen-okta the possibility of making this an SDK configuration option so we could increase the 10 minute threshold to something like 30 minutes and reduce the number of impacted users. Can we please move forward with this request?

JayNewstrom commented 2 years ago

Hi, thanks for bringing this up! I've added an issue to our backlog for this enhancement. OKTA-414753

Thanks!

thereallukesimpson commented 2 years ago

Thanks, Jay. Are you able to provide an rough ETA for this feature to become available? Are we talking weeks or more likely months?

JayNewstrom commented 2 years ago

We don't typically give ETAs, but I'll make sure our project manager knows about this. Thanks!

JayNewstrom commented 2 years ago

The fix provided in https://github.com/okta/okta-oidc-android/pull/281 will allow you to do this.

When creating your OIDCConfig, you can now call idTokenValidator and pass a custom validator in. Your validate method should do something along the lines of what the new DefaultValidator does, but it doesn't have to, and could do nothing. As long as that method doesn't throw, it'll store the tokens and allow you to use them.

We'd recommend you implement that interface with a similar implementation as our default, but one using a synchronized time source. Such as https://github.com/instacart/truetime-android

I'm hoping to wrap the PR up, and release it tomorrow.

JayNewstrom commented 2 years ago

@thereallukesimpson I just released 1.2.0 with this functionality. Could you please give it a try and report back?

thereallukesimpson commented 2 years ago

Hi @JayNewstrom. Wondered if you considered exposing the Clock interface, which would allow us to use the DefaultValidator with the Truetime library you mention?

thereallukesimpson commented 2 years ago

Also, can I ask why you wouldn't implement the Truetime synchronized time source as part of the SDK?

thereallukesimpson commented 2 years ago

Lastly, I can't access mClaims in the OktaIdToken as done by the DefaultValidator in order to check oktaIdToken.mClaims.exp and oktaIdToken.mClaims.iat.

Error: Cannot access 'mClaims': it is package-private in 'OktaIdToken'

Please let me know how I should access these values.

JayNewstrom commented 2 years ago

Lastly, I can't access mClaims in the OktaIdToken as done by the DefaultValidator in order to check oktaIdToken.mClaims.exp and oktaIdToken.mClaims.iat.

Error: Cannot access 'mClaims': it is package-private in 'OktaIdToken'

Please let me know how I should access these values.

You can use the getClaims method which access the same variable.

Also, can I ask why you wouldn't implement the Truetime synchronized time source as part of the SDK?

We will consider adding this at a later date, but for right now we wanted to minimize the scope of the change, and adding dependencies to the project.

Hi @JayNewstrom. Wondered if you considered exposing the Clock interface, which would allow us to use the DefaultValidator with the Truetime library you mention?

We plan to leave this internal for now. This allows us the flexibility to change the implementation as needed.