manfredsteyer / angular-oauth2-oidc

Support for OAuth 2 and OpenId Connect (OIDC) in Angular.
MIT License
1.88k stars 686 forks source link

Custom Date Provider set time asynchronously #1118

Open YusufIpek opened 3 years ago

YusufIpek commented 3 years ago

Is your feature request related to a problem? Please describe. With the newly added DateTimeProvider the user can set its own time, but is it possible to set the time asynchronously? Is it possible to convert the methods 'now' and 'new' to async methods?

Describe the solution you'd like Fetch the time from a server and use that time to validate the expiration of the token.

jeroenheijmans commented 3 years ago

Ooh... that would complicate things quite a bit though? Either it would be a breaking change, or there would need to be both sync and async methods and some kind of fallback. All the code that uses these methods would also become far more complicated, with possible strange side effects.

I appreciate you may have a use case for this (and would also be curious to learn what it is?), but at first glance I'm not sure if such a change would benefit the community as a whole.

YusufIpek commented 3 years ago

A use case could be the following: For example, the local time on the user's computer might be wrong (for some reason), by retrieving the time from a server we can guarantee that the time is correct. If the time on the user's computer is wrong, the token validation will most likely fail, because we get the token expire time from the server and the current time from the user's computer.

YusufIpek commented 3 years ago

Possible solution I have the following idea, but I don't know if it would work. What if we can calculate the offset to the servers time? In the http response we get the 'date' field, which is the servers current time, by calculating the difference to Date.now() we get the offset. That offset should be added in the now and new method of the DateTimeProvider.

jeroenheijmans commented 3 years ago

Oh whelp, that's one tough scenario.

Beware that if you mess with date/time like this, that you're explicitly punching holes in the security of the protocols. I'd go pretty far in asking folks to make sure their system time is reasonably correct, before working around the issue in your security layers.

I don't think it's worth the extra complexity and/or breaking changes to this library to support your scenario. I partially say so as you'll have a pretty good workaround I think:

I recommend creating an asynchronous APP_INITIALIZER that does what you described: get the API time, and save an "offset" for the time on the user's computer. You can use this offset from there on out to provide a service for now/getdate to the oauth library that is synchronous.

Hope that helps.