Profile avatar
skye.soss.website
I study Programming Languages @skyb0rg on Twitter
27 posts 57 followers 106 following
Getting Started
Conversation Starter
comment in response to post
Ignoring the whole “revocation is impossible” thing I think it’s pretty cool to have a completely stateless database.
comment in response to post
I think in this case it’s actually the exact limit. Because a dev can ask for a non-revocable token with a 24 hour lifetime.
comment in response to post
You should try an app with OAuth2-based access permissions like an app with read-only access to calendar. I think GMail may just not use JWTs
comment in response to post
I’m thinking more: phone with WiFi -> phone on 4G -> phone on 5G -> VPN Though maybe Google rejects QUIC session resumptions from different world regions.
comment in response to post
That’s interesting, I didn’t think Google could get away with grouping device by IP address because of their use of QUIC.
comment in response to post
The whole point is that the server receiving the JWT doesn’t need to make any request to the central server, just check the time + signature. Checking that the token isn’t revoked every time a JWT-based access token is used defeats the purpose of JWTs.
comment in response to post
But Google doesn’t support access token revocation for JWT-based access tokens, same as Microsoft. I assume GMail doesn’t use JWTs since there aren’t complex access rules for email (or if there are it isn’t common). cloud.google.com/apigee/docs/...
comment in response to post
Google does seem to implement access token revocation, something Microsoft doesn’t. Also Microsoft access token validity goes down to 10 minutes but I’m not sure what the length is per-app. learn.microsoft.com/en-us/entra/...
comment in response to post
Yes and instantaneous revocation requires a central database containing all of the access tokens and their revocation status, queried on every request. Thats the whole motivation of the refresh vs access token separation of OAuth2: no need to query every request just on refresh.
comment in response to post
That requires the identity provider to validate the bearer on *every* request, which is not feasible. Even if you use Google and explicitly setup access token revocation it is still cached for 3min. cloud.google.com/apigee/docs/...
comment in response to post
You got me. As far as I could find online all of Microsoft’s own services set the max validity to 1hr, so you should be fine after that. The 24hr number is just the maximum an app that use Microsoft sign in could ask for.
comment in response to post
Gmail does have this same limitation, though a smaller time window since its access token validity period is <=1hr. For Microsoft Azure (at least) this is also true. The 24 hr number is the max time configurable by an app using Microsoft’s identity: most are 1hr.
comment in response to post
This is a technical limitation of JWTs not specific to Microsoft. Every website with a “Sign me out of everywhere” button has the same limitation because the “I am logged in” data is not stored on Microsoft servers.
comment in response to post
That’s it?
comment in response to post
SML fixes this
comment in response to post
Wow, first day on BlueSky and already disparaging us. Looks like you’re getting a BLOCK (Did I do this right)
comment in response to post
Looking into it
comment in response to post
When this post is eventually deleted we will know that BlueSky is truly a Twitter clone.