Proposal: SwiftNIO based OAuth 2 Provider project

Server Pitches
1

Pitch

An OAuth 2.0 Provider library built on top of Swift NIO. Implementing RFC 6749, 6750 and 7662.

Motivations:

OAuth 2.0 is a popular authorisation framework used by many large applications. It allows smaller sites and applications to delegate authorisation (and authentication....ish) to large providers, such as Google and Facebook to allow them to manage the user information.

It also provides methods for users to allow 3rd party (and first party) applications access to their data, such as Twitter clients. Finally, it's popular amongst microservice architectures as a way of checking authorisation for different services.

Having an OAuth 2.0 provider library is important for any web framework. I know there is demand for this in Swift.

Development Plan:

Currently there is a server-side Swift project for Vapor 2 - GitHub - brokenhandsio/vapor-oauth: OAuth2 Provider Library for Vapor. This has an extensive test suite to cover the behaviour and different specs. A lot of this can probably be ported over. It has a dependency on Vapor, but no dependencies on any databases. All data layers are abstracted away, so this should be a case of converting all the that to EventLoopFutures. There will be some work to remove the Vapor dependencies on the routing logic and tests.

I did write the code quite a long time ago so it can probably do with some updating or writing with another years experience. I also promise to spell authorisation incorrectly throughout....

Original Message:

So I may open a can of worms with this, but might as well get it started at some point!

In the next month or two I will be migrating my OAuth 2.0 Provider library, GitHub - brokenhandsio/vapor-oauth: OAuth2 Provider Library for Vapor, to Vapor 3. I might as well take the opportunity to make it sit on top of Swift NIO and propose it as a project for the Server Working Group. It should be relatively straightforward to port to NIO, since all the data layers are abstracted away.

The project implements RFC 6749, 6750 and 7662 and has tests for all parts of the specs.

I know the process for incubation etc hasn't been defined but could be a fun one to start with!

Thoughts?

13 Likes
2

Something which doesn't require Vapor would be awesome!

3

Yeah, I should have made it clearer. The idea would be to port the bulk of the package to SwiftNIO only and then have separate packages which are just thin wrappers for Vapor/Kitura etc

8 Likes
4

Love it, sounds great.

3 Likes
5

Also a fan :+1:

6

That sounds great, @tomerd just posted the RFC for the SSWG Incubation Process. Do check it out and give us feedback what you like and what you don't :slight_smile:. Once some version of this is accepted you can just follow it for the OAuth 2 Provider project.

1 Like
7

@0xTim should we move this discussion to the new pitches category?

1 Like
8

Yep! Was going to create a fresh post in pitches with a bit of a deeper explanation/overview unless you’re happy to just move this?

1 Like
9

done, tho +1 on deeper explanation/overview

10

Ok pitch updated! Looking forward to the comments :smile:

2 Likes