Add Security Metadata Extension

[rwinch]

I'd like to propose creating standard metadata extensions for the purpose of authenticating users. I'd like to ensure we have support for both username/password and bearer token based credentials.

I think this would include two different metadata MIME Types, but am open to suggestions. Below is a first attempt at defining the support I have in mind.

Valid Frame Types

Both metadata types can be used for either/or a connection or a stream. This will allow authentication to happen at the time of connection and/or per stream. This is important because authentication/authorization might happen on a per connection basis. For example, a mobile device might only provide credentials at the time of connection.

However, a web application might have authentication/authorization required to establish a connection and then rely on specific user level credentials (i.e. an OAuth Token from the web application user) for authentication/authorization on each stream.

Basic

The first metadata MIME Type I'd like to propose is message/x.rsocket.authentication.basic.v0. The metadata contains a username and password in the format of <username-length-in-bytes><username-string><password>.

Bearer

The second metadata MIME Type I'd like to propose is message/x.rsocket.authentication.bearer.v0. The metadata contains a bearer token in the format of <bearer-token-string>. In this case a bearer token is defined as a string that when presented grants the "bearer" of the token access so a resource. This conforms with the OAuth definition of bearer tokens, but is also applicable for in a broader sense (i.e. session ids).

[yschimke]

I’m slightly biased against binary encoding in the first case. But I suspect in JS environments using the bearer token is probably more common. Could the HTTP basic encoding also work for the first case?

[rwinch]

Thanks for the prompt response.

I’m slightly biased against binary encoding in the first case.

I'm far from a JavaScript expert, but can't it also support binary encoding? To be clear I'm open to changes in the proposal, but I'm not certain I understand the hangup of using binary encoding.

But I suspect in JS environments using the bearer token is probably more common.

I think there are cases where JavaScript might want to use username/password based credentials. For example, the client might use a username/password grant to establish an OAuth token in the first place.

Could the HTTP basic encoding also work for the first case?

I initially considered this, but it has a few drawbacks.

• HTTP Basic does not allow a : in the username field. While this is probably not an issue in practice, it seems to be an unnecessary limitation.
• HTTP Basic will Base64 encode the credentials to encode non-HTTP-compatible characters. This encoding is unnecessary in RSocket.
• By default HTTP Basic requires US-ASCII compatible encoding. Internationalization support is defined, but is an afterthought squeezed into the updated RFC vs first class.
• It is not as efficient and it might be included in every request stream.

We could also go with a variation of HTTP Basic. For example UTF-8 Strings with <username><delimiter><password> but then the username cannot contain whatever that delimiter is.

[yschimke]

None of my points are blocking. So suggest waiting for other discussion. I’m excited to see this happen.

[robertroeser]

HTTP Basic will Base64 encode the credentials to encode non-HTTP-compatible characters. This encoding is unnecessary in RSocket.

I agree it's unnecessary - my question is though is this going to be coming from that is already base64 encoding the information? It would be worse to decode it if was already base64 encode.

Is this meant as a way to send standard security information via RSocket?

[rwinch]

I agree it's unnecessary - my question is though is this going to be coming from that is already base64 encoding the information? It would be worse to decode it if was already base64 encode.

I'm not sure I understand the question, but I'll try and answer it.

I don't think there is any reason an application would have a base64(username:password) value that would then need to be decoded.

Even when HTTP Basic Authentication is accepted by a web application, the username/password needs to be extracted to perform authentication. From the client side, the client is going to ask for the raw username/password and base64(username:password) only if the downstream service needs to use HTTP Basic.

In short, the raw username/password should be available without the need to base64 decode it.

Is this meant as a way to send standard security information via RSocket?

I'm looking to provide a standardized way to provide a username/password and a bearer token (i.e. OAuth Token, Session ID, etc).

[yschimke]

Another way to look at this though is that there are standard ways to encode these credentials already. You could also encode JWT tokens with another implementation. But why bother.

[rwinch]

Another way to look at this though is that there are standard ways to encode these credentials already.

I'm guessing this is in regards to HTTP Basic. If it is, I'd like to emphasize that, as with everything, context matters.

HTTP Basic encoding username/password makes sense when it is included in an HTTP header so that it can be parsed in that context. However, leveraging a username/password in another context means that it should be encoded accordingly.

For example, web applications that use HTML form based authentication do not use HTTP Basic encoding (this is a large number, if not majority, of web applications). In that case, the username/password is encoded with application/x-www-form-urlencoded within the body of the HTTP request.

Given that context matters for encoding, I don't think that HTTP Basic encoding makes sense for username/passwords in RSocket. HTTP Basic encoding uses base64 encoding to escape characters that should not be allowed in an HTTP header. RSocket does not have this limitation, so there is no need to perform base64 encoding.

[robertroeser]

@rwinch I guess the next step is to write this up as an ext then like the other ones we have, and add a pull request to add this the well-know metadata for the composite metadata spec.