Implementing token backend persistency

[Freyskeyd]

Feature

Currently when using oxide-auth within an api which will be deploy multiple times with a LB on front we can't rely on the internal vector which hold the generated tokens.

We need to be able to share a common backend for those tokens to allow multiple instance to access those DB and check for the tokens validity.

I was thinking of Redis but other connectors can be implemented.

Alternatives

I don't really see any alternatives to a shared backend storage.

[asonix]

this can be done by implementing oxide primitives like the Authorizor, Issuer, and Registrar traits for a custom backend. I don't think it is oxide-auth's job to provide these, since then it would be declaring a blessed database.

[MatteoJoliveau]

It is at least necessary to add async/await support as many persistence libraries as well as frontend frameworks like Actix already make use of this feature. @HeroicKatora can you give an update regarding these topics? I know you probably don't have much time to spare at the moment but these are pretty essential features to have. I'm currently writing my own OAuth implementation because Oxide is dragging behind the rest of the ecosystem and I had troubles integrating it with Actix Web 2.0 (pending PR by @gzp-crey here) and Reqwest (I use CouchDB as my database).

[DanielJoyce]

I think an Async Api is more critical for this reason, interfacing with storage.

[HeroicKatora]

Sorry for not updating this explicitly, async is possible since 0.5.0 and there are utility bindings based on async-trait for it as well.