Abstract

This document presents a few common authentication options that could be considered for the OSDM standard, including a proposal which is the preferred solution for BeNe. The document concludes with the minimal common denominator that should in any case be part of the standard.

Context

While mostly focussing on functional aspects of the standards, the OSDM experts workgroup as already a few times discussed the topic of security, specifically authentication and authorization.under the following angles :

• In the early phases oft he initiatives, we had some discussions going mostly about the technology to be used. There were some discussions as well on whether security was at all something that should be part of the standard, and if yes, which aspects of security. The outcome was : ** We want to use OAuth2 for authentication ** We leave authorization schemes to the choice of implementers ** We take a « security by design” approach when it comes to designing endpoint, primarily with GDPR concerns in mind.
• More recently, we discussed the opportunity to use token factories, and the question became even more pressing as Sqills rolled out its first draft implementation of an OSDM-compatible set of endpoints, running on top of its existing inventory system.
• In the internal review on the proposed mechanism at BeNeRail, it came up that the currently proposed mechanism had been in place on some of our systems… until being flagged for review in security audit requested by one of our clients. This led tot he present discussion.

Authentication options

This section covers the various authentication options that have been discussed.

Basic authentication

The most basic way of applying authentication is by simply requesting a user & password in the header of each incoming message

This mechanism is obviously now obsolete and not secure enough for a modern standard. It was actually from the start excluded de facto by the decision to use OAuth2

Authentication via token factory on provider side

The next proposal was to have the OSDM provider propose a „token factory“ endpoint, that would be part of the standard, and generate a JWT token upon request. The request here should contain identifier for the consumer requesting the token (in the proposal: loing and password).That JWT token would then be used for some time by the conumer in each request to the OSDM provider. When the JWT expires, a new one is requested.

Unfortunately, this approach still presents several weaknesses:

• It is somewhat constraining for the provider, who is now forced to expose a token factory
• The fact that the initial token is still requested based on login/password defeats the purpose of having a token, and makes this mechanism almost as vulnerable as the plain login/password approach. An attacker could capture these and then even request is own JWTs
• The JWT generated itself can be intercepted and again used by a malicious user in fraudulent requests. While indeed using the OAuth technology, this model actually fails at implementing a key aspect present in all OpenID connect authentication mechanisms: digital signature

BeNe proposal : digitally signed self-issued tokens

Since the OSDM will mostly address server to server connections, the proposal is to rely on digitally signed self-issued JWT token as exposed in the schema hereunder.

(note that the secure location needs to be secure in terms of modification, reading is not an issue: Even in possession of the public key, an attacker could only authenticate messages from the consumer, not produce new ones) The key element here is that the token is digitally with the private key of the consumer. This is what really authenticates the message fort he provider (decrypting with the public key of the claimed consumer results in a valid, non-expired JWT).

Since the JWT is extremely short lived, even in case an attacker managed to get his hands on a JWT, there is virtually no chance it is still usable.

Variations

• There are several mechanisms described on the OpenID connect website on how to publish public keys, from the simple email transmission to publishing on an agreed location to providing the key location in the message itself, via a certifiate authority.
• The recommendation here is that the provider uses a different JWT token (or a completely different authorization mechanism) to check authorizations of the consumer internally. However this remains a choice left to the implementer
• In order to serve the case where a consumer would not be in state, or not willing to generate a selissued JWT, token factory could be proposed by the provider. The important part here being the the JWT remains short-lived (maybe 2x timeout would not be sufficient anymore) digitally signed by the consumer.

Minimal common denominator to include in the OSDM standard

Based on the above, the following conclusions come out as the minimal common denominator of what needs to be part of the OSDM standard definition :

• The JWTs in use for the authentication should be short-lived (think of timeout duration single-digit multiples)
• The JWTs sent by the consumer, regardless of where they are generated, must be digitally signed using a private key for which the provider is able to find the matching public key

The following aspects should not be part of the standard to allow organization finding the best fit for their own infrastructure and security policies :

• The authorization mechanism to be used internally by the provider logic
• The publication mechanism of the public key (as long as it is secure)
• The fixed duration of the token lifetime
• The exposure by the provider of a token factory to generate the JWTs for the consumers In all case, the only conditions regarding the grammar of the API calls is the presence in request headers of a token element, where the digitally signed JWT can fit.