This implements #70 by reworking the main crate into explicit state machines. A new crate then has the actual async bindings that use the state machines differently than the synchronous methods. At some point in the future these will hopefully be rewritten into proper generators with arguments instead. This PR is a work in progress.

TODO:

• [x] OwnerSolicitor
• [x] access_token
• [x] authorization (claimed by @Geobert)
• [x] refresh
• [x] resource

Merge overview:

• [ ] This change has tests (remove for doc only)
• [ ] This change has documentation
• [x] Corresponds to issue #70

Project Improvement

actix-web 1.x has some breaking changes. The library and examples need to be updated to remain useful.

Tracking pull request

• [ ] A pull request (does not yet exist)

Feature

Actix is arguably a quickly evolving library and its web framework has been proven to be very performant.

The greatest challenge is translation between Future structures and the sequential handling of requests here.

Tracking pull request

• [x] The development branch has been merged into dev-v0.4.0

This change splits ring, and types based on ring-backed types, into another crate to avoid a hard dependency on Ring. A lot of the concrete implementation does depend on ring, so a good deal of tests have moved over into the ring crate, also

• [x] I have read the contribution guidelines
• [x] This change has tests (remove for doc only)
• [x] This change has documentation
• [x] Corresponds to issue #55

No real changes, just added serde_urlencoded to the db-example sub-project

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Project Improvement

actix-web 2.x has some breaking changes and comes with support for standard futures.

Other context

See prior comments in #37. It also requires an update to ring to support v0.16.

Tracking pull request

• [x] A pull request is #72
• Related: #63
• [x] Motivates: #70

• [x] I have read the contribution guidelines
• [x] This change has tests (does the example count?)
• [x] This change has documentation
• [x] Corresponds to issue #37

I'm opening the PR to get help because it doesn't compile and I'm kinda stuck :(

error[E0499]: cannot borrow `authorization` as mutable more than once at a time
   --> oxide-auth\src\code_grant\authorization.rs:332:27
    |
332 |         requested = match authorization.advance(input) {
    |                           ^^^^^^^^^^^^^ mutable borrow starts here in previous iteration of loop

I'm wondering why I get this error when I'm doing things in a similar way to other flows :-/

Use rustfmt for code.

The only thing not rustfmt related is .gitignore to avoid pushing VSCode config files.

For some reason, rustfmt seems to do a "all-features" parse, so I needed to add empty files for modules that where feature gated and not present.

And it seems that rustfmt has issue with #[path] so added some #[rustfmt::skip] on them.

• [x] I have read the [contribution guidelines][Contributing]

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

This fixes

• [x] I have read the [contribution guidelines][Contributing]
• [ ] This change has tests (remove for doc only)
• [x] Corresponds to issue (#89)

I'm not sure on how to stub to write a test. But the change seems trivial.

Hi,

One major improvement I'd like to see is to have option to carry the authentication flow state in external database - my use case would use REDIS. The rationale for it is to support clustered environment with load balancer in front, with minimal intelligence in the network boxes.

I'd be happy to make a PR about this myself, if you are happy with the concept and can point me in right direction.

Various version bumps.

• [x] I have read the contribution guidelines
• [ ] This change has tests (remove for doc only)
• [ ] This change has documentation
• [ ] Corresponds to issue (number)

This fixes timestamp deprecation warning by moving to timestamp_opt() as the behavior of timestamp() is to panic on error.

• [x] I have read the contribution guidelines
• [ ] This change has tests (remove for doc only)
• [ ] This change has documentation
• [ ] Corresponds to issue (number)

Project Improvement

The link to the changelog in the readme.md returns a 404. Obviously, that doesn't stop anyone from using oxide-auth but it would be nice if it was fixed at some point. Thanks.

I'm implementing a server that supports pretty standard Auhorization Code flow. I'd like to generate both access and refresh tokens, the former with short expiry time, the latter with long expiry time. I kinda struggle with how to implement this. Since those tokens are tied one to another, I implemented a single Issuer (which I'm using with a Generic endpoint). From what I saw in examples and implementation of TokenMap, expiry time is taken from Grant that is passed to the issuer. This however implies that maybe I should implement different Issuer for both access and refresh grants? This however doesn't make sense either since I need to use different - and probably somehow hardcoded - expiry times for both of those tokens. Or perhaps I don't understand where this Grant instance comes from when implementing an Issuer.

On thing that confuses me on top of this is how to set different access and refresh token expiry times when using TokenMap. It seems to me that they are always set to the same expiry time and it cannot be changed.

Maybe this is also related to #117 and I'd be happy to help out with some examples once I understand how to implement this.

This PR fixes ~40+ clippy warnings and documentation typos in the main crate, along with many others in the subsequent crates for those using oxide-auth.

This also bumps oxide-auth and all its related crates by 1 minor version to comply with SemVer(lots of Into -> Froms, possible breaking API changes) and to update the oxide-auth to 0.6

• [x] I have read the [contribution guidelines][Contributing]

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.