There's two ways to approach it. One is, as you're describing, to have a central store of currently valid tokens, and check against that.
The other is to have tokens that contain information on what permissions they grant and when they expire, with a cryptographic signature to prevent tampering. Then you don't need a central store; the server receives a token, checks that it is in date and gives the necessary permission, and checks that it was correctly signed. However, you do need a central store if you want to invalidate tokens before they expire. It's not ever-growing, though, because once an invalidated token has expired, you can discard it from the list. Thomas On 22 January 2018 at 20:04, Lawrence D’Oliveiro <[email protected]> wrote: > On Monday, January 22, 2018 at 9:07:20 PM UTC+13, Roland Weber wrote: > >> >> On Saturday, January 20, 2018 at 12:08:16 AM UTC+1, Lawrence D’Oliveiro >> wrote: >> > >> > Surely it’s the other way round, the usual practice being to maintain a >>> store of *valid* tokens, with a finite lifetime attached to each >>> (perhaps reset when they get presented again). The tokens get deleted >>> either on explicit logout or implicitly on lifetime expiry. Anything that >>> isn’t currently recognized from the store entries is invalid. >>> >> >> Nope, that would require a central store of tokens. >> > > Which you have to have somewhere anyway. > > >> In single sign-on environments, or with more complex authentication >> schemes like OAuth, web servers have to accept tokens that were issued >> elsewhere. They don't know about a token until it is presented to them. >> > > Don’t they have to check back with the issuing server(s) to validate those > tokens anyway? Then if they pass, keep them in a local cache for some > reasonable time, either until their expiry (if that’s not too long) or > until they need to be rechecked for validity. Either way, you do *not* > want to maintain an ever-growing store of *invalid* tokens, only a > limited and regularly-pruned store of *valid* ones. > > This is all just basic security stuff. > > -- > You received this message because you are subscribed to the Google Groups > "Project Jupyter" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jupyter/c8921e7d-e9cc-4c52-8900-434d55a38406%40googlegroups.com > <https://groups.google.com/d/msgid/jupyter/c8921e7d-e9cc-4c52-8900-434d55a38406%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAOvn4qg7SmOH_F0Ef-vdKSiUBcr3zy%2BFxUmJfXWn5XH4Gr80mA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
