OAuth not conforming to spec; returns existing token instead of granting a new one

[haydenmc]

Per @danstiner's comment here:

[...] glimesh.tv doesn't quite follow the OAuth 2.0 spec for granting tokens. Which is understandable, I feel libraries do a bad job of explaining the flow. Basically Glimesh.tv will return your current access token (if it's still active) instead of granting a new one: https://github.com/Glimesh/glimesh.tv/blob/dcfff8d60743a603ca24ebb156e08287920c7d6a/lib/glimesh/oauth/oauth_token_handler.ex#L149

The spec says every request should get a new access token, and the library https://github.com/danschultzer/ex_oauth2_provider used assumes this as well. So we end up in a weird place where you request one token, then request a new one and hour later and get exactly the same response with the same token and same expires_in value, despite the token being one hour closer to expiring: https://tools.ietf.org/html/rfc6749#section-5.1

The [Janus-FTL] glimesh service connection works around this by using created_at, which works for now but has a couple problems. First, it's not part of the OAuth spec so other clients won't follow this approach, they'll expect a new token. Second, clients can't preemptively get a new access token before the current one expires to avoid interruptions (because they'll just get back the current token until it expires). Third, a fun finding I had was created_at is in the timezone of the Glimesh.tv server. Luckily that's UTC for the actual production service but I had some really fun issues locally when multipass created VMs in the PST timezone. Correctly issuing a new token every time and just relying on expires_in should avoid all these problems and work better with oauth client libraries that our users will probably be using to connect to glimesh.tv.

[clone1018]

AFAIK this is fixed with the new Boruta OAuth Issuer.

[danstiner]

Indeed it is! Closing.