Swift Authentication

Server Pitches
1

I have a proof of concept implementation of this package available on GitHub.

Introduction

This pitch proposes the introduction of an Authentication package, which will provide lightweight yet opinionated abstractions enabling developers to build secure authentication systems in Swift.

Motivation

As adoption of Swift on the server continues to increase, and the server-side Swift ecosystem grows (e.g. with introduction of Swift Service Discovery), various approaches to building authentication and authorization mechanisms are likely to pop up. Swift Authentication seeks to address the former challenge. (I have also worked on a complimentary Swift Authorization package, but that's for another day.)

Swift Authentication aims to address sensitive use cases that could have profound security implications. An openly-available package with good documentation (and perhaps more importantly, recommendations) made available in the IDE (Xcode or otherwise) could make Swift an even more attractive solution for building services with authentication requirements.

Related Work

Notably, Apple has an existing AuthenticationServices framework that is very similar to this proposed package. There are two key reasons I believe they can co-exist:

  1. Swift Authentication is/will be available as open source, accepting contributions and being generally steered by the larger Swift community.
  2. Swift Authentication will be platform agnostic, whereas Apple's AuthenticationServices framework is primarily meant (and includes features) specific to Apple platforms.

Hypothetically, the AuthenticationServices framework from Apple could eventually leverage Swift Authentication under the hood.

Implementation

The surface area of this package is minimal by design. Authentication occurs in many different contexts, relying on various different pieces of information. Because we can't predict what all those contexts might be, the general purpose of the package is encapsulated in an AuthenticationService protocol.

Beyond that, Swift Authentication will shine by providing a suite of opinionated credential implementations that can be used to accelerate the development of secure authentication systems. The only example in my proof of concept is the UsernamePasswordCredential. This is similar to the ASPasswordCredential defined in the Apple AuthenticationServices framework.

Potential areas for other credentials:

  • OpenID Connect
  • Public key cryptosystems
  • FIDO U2F

Conclusion

I think that it would make sense for the Swift Server Working Group to pursue an opinionated authentication package, such as Swift Authentication, to encourage the usage of Swift for building cross-platform services with authentication requirements.

Direct contributions via GitHub to the package are welcome as well. Further discussion, issues, PRs, etc. You can also ping me on Twitter (@sjroot) to discuss further.

8 Likes
2

CC @lukasa

3

Thanks for starting this.

Will it work with something like SQRL ?

4

This is an interesting pitch. Right now I have mixed feelings about it, mostly because the initial pitch is extremely barebones. In principle I think this framework can have a lot of value, but it needs a bit more of a roadmap to handling more complex use-cases.

As an example let’s consider something like HTTP Digest Auth. This requires the ability to issue an authorisation challenge containing a number of fields. The authentication package as specified today doesn’t have a general-purpose way to structure this kind of challenge. While nominally this information can go into the AuthenticationFailure object, that type is currently almost entirely unconstrained. That forces users to handle the concrete type anyway.

This package also has no general notion of a user. That makes it very tricky to adopt in a generic context, which is the primary reason for an abstraction package like this to exist. We’ll need to define one, even it’s just a User protocol with a few computed properties on it that can be shimmed by arbitrary frameworks.

I think this package would be substantially more compelling if it took on addressing some common cases of more complex auth flows. Let’s see how HTTP 401 challenges should flow, let’s see how webauthn should flow. That gives a much more compelling story, IMO, because it allows frameworks like Vapor to provide generic middlewares that can plug arbitrary authentication objects in.

Other directions worth investigating are persistence (some auth services need persistent data, what do I need to serialize and how must it be keyed?) and perhaps some API for expressing how credentials may be constructed from certain data sources (e.g. HTTP headers).

I think this general idea has a lot of promise, but it is currently in a very early stage, and would benefit from more development in the OSS before being adopted by the SSWG. For my part, I think I’d be most convinced by seeing a generic implementation that can handle both HTTP Digest and at least some limited webauthn flows, plus evidence that this can support a Vapor middleware. That gives us a really good idea that the core implementation is on solid ground.

2 Likes
5

Thanks for the reply @lukasa! You're absolutely right about the package being very early stage, and the kind of feedback you've provided was exactly what I was hoping for at this point. I think we are on the same page regarding the roadmap. Specifically, I added a tracking issue for web-related features.

I've addressed this with a new Credential protocol, which should ensure that all derived credentials are tied to some type of identity (user, client, or otherwise).