Questions re: authentication and credential refresh

[spencerwilson]

Expected Behaviour
Some docs exist that speak to how authentication with credential refresh may be implemented atop this protocol.

Actual Behaviour
None exists.

Further Information
As a user of the old subprotocol graphql-ws, I'm accustomed to putting an authentication credential in the GQL_CONNECTION_INIT message's payload. Analogously, in graphql-transport-ws I can equally well put the credential in the ConnectionInit message's payload. That is, both protocols have features that can be leveraged for connection-level, one-time conveyance of authentication credentials.

I operate a GraphQL server and would like to abort long-running operations (presently just subscriptions) when their associated authentication expires. It would be wrong from a security perspective to allow unending access to confidential data on subscriptions long after we cease to trust the credential on whose basis the subscription was initially authorized.

Tangent: Regarding "authentication is connection-scoped" vs "operation-scoped":

• graphql-ws GQL_START has no "extensibility point" that might be used to carry per-operation credentials;
• graphql-transport-ws does have such an extensibility point: Subscribe, in its payload.extensions. Credentials could be included there.

Regardless of if authentication is connection- or operation-scoped, the ideal UX from a client's perspective is that there be some mechanism to refresh credentials for incomplete operations on the connection. To satisfy all the stated requirements, graphql-transport-ws could be used in the following way:

• Clients enclose credentials in ConnectionInit's payload. These credentials are associated with all operations on the connection.
• Clients refresh the connection's credentials by enclosing some data on the payloads of occasional Ping messages.

Given that we should be careful about what's in scope of this protocol and what's not, my question is admittedly vague:

1. Do you have any opinion or reaction to this usage of the protocol? E.g., does it seem like an abuse of the Ping message?
2. Would you consider documenting this paradigm for authentication as non-normative, outside-of-spec "guidance"? I assume that admins of GraphQL servers that serve confidential data have these same needs.

[enisdenjo]

Since WebSocket connections cannot be hijacked, I personally don't bother much. I know for a fact that the identity resolved during the connection initialization process is persisted as long as the connection is alive - so, re-authenticating within an active connection is kinda useless if you ask me.

Of course, there are cases where you want to kick the client off - like when the user gets his rights revoked while being connected - but, these cases can be solved differently: keep a map of all user IDs with connected sockets and simply close the socket behind a user ID whenever he's deemed unauthorized.

Additionally, if you worry about connections being alive for too long, simply set a limit of how long a single connection can live and close the connection after the timeout.

Do you have any opinion or reaction to this usage of the protocol? E.g., does it seem like an abuse of the Ping message?

No, on the contrary, the ping's payload is meant to be used for any sort of keep-alive logic - be it authentication or latency metrics. However, I'd still prefer closing the connection with the client and have the client re-authenticate by repeating the connection initialization process.

Would you consider documenting this paradigm for authentication as non-normative, outside-of-spec "guidance"? I assume that admins of GraphQL servers that serve confidential data have these same needs.

No, not really. TBH I'd rather leave it to the implementer to decide how his authentication/authorization works since there is no one-size-fits-all here - I'd rather not have an opinion. Additionally, there's an abundance of WebSocket security articles on the internet which were written by much smarter people than me.

[spencerwilson]

the identity resolved during the connection initialization process is persisted as long as the connection is alive

Are you referring to some specific GraphQL server framework here? Or perhaps you're referring to how in https://github.com/graphql/graphql-js the same context value is given to every resolver call made while handling events on the subscription's source stream (src)? If so, I'll note that that object's mutable, so the server could mutate it arbitrarily depending on data received in, say, a Ping payload.

It would be wrong from a security perspective to allow unending access to confidential data on subscriptions long after we cease to trust the credential on whose basis the subscription was initially authorized.

[I disagree.] re-authenticating within an active connection is kinda useless if you ask me.

To clarify, the situation I had in mind is this:

Eve steals Alice's API token. Ordinarily the risk of data breach in this situation is mitigated by the token having a short expiry. In this case, though, Eve can open up a WebSocket to the API and have the powers granted by the token for as long as she can keep the WebSocket open, effectively bypassing the token's expiration.

What do you think of that scenario?

set a limit of how long a single connection can live and close the connection after the timeout.

I agree that would mitigate the data breach risk. It has the unfortunate downside that it adds forced "downtime" for subscribers who want to stay alive indefinitely, and if required could refresh their credentials. That said, GraphQL subscriptions by their nature have "at most once" delivery guarantees anyway; the network could partition at any moment and the client would miss data published during that time. So maybe adding downtime to an already fundamentally unreliable mechanism of data broadcasting isn't actually a big deal.

We're going to implement server-enforced connection timeouts and accept that clients will just have to reconnect. Thank you for the response!

[enisdenjo]

Are you referring to some specific GraphQL server framework here?

No, nothing framework specific. I am simply saying that a WebSocket connection is between the server and the distinct client as long as it is alive. You cannot transfer a WebSocket connection to another client.

Eve steals Alice's API token. Ordinarily the risk of data breach in this situation is mitigated by the token having a short expiry. In this case, though, Eve can open up a WebSocket to the API and have the powers granted by the token for as long as she can keep the WebSocket open, effectively bypassing the token's expiration.

What do you think of that scenario?

Two possible solutions: set a timer on connect that closes the connection after the token's expiry; or centralise the management of tokens and subscribe to the store from the WS server, whenever a token gets revoked, propagate the event to the WS server and close the related connection.

It has the unfortunate downside that it adds forced "downtime" for subscribers who want to stay alive indefinitely, and if required could refresh their credentials.

That is true. A way to circumvent the downtime is to indeed use the ping/pong messages and transmit up-to-date credentials that the server validates when receiving a ping/pong.

[blevine]

FWIW, in my keycloak-graphql project, I've taken the approach of making the client responsible for authenticating and obtaining an access token. The graphql-transport-ws Ping and Pong messages are used as follows:

1. The client obtains an access token from some IdP and passes the access token as part of the payload in the ConnectionInit message.
2. The server validates the access token and stores it a server-side session associated with the socket. If the access token cannot be validated, the socket is closed.
3. On the server, the access token's expiration time is retrieved and a timer is started that times out just before the access token expires.
4. When the timer expires, a Ping message is sent to the client with a payload indicating that the access token has expired.
5. The client is then responsible for contacting the IdP to obtain a new access token (i.e., by refresh or re-authentication).
6. The client sends the new access token back in the payload of a Pong message.
7. The server validates the access token and stores it in the session. If the access token cannot be validated, the socket is closed.

When the client creates a new subscription, the access token is retrieved from the session, validated, and added to the GraphQL context making it available to the resolvers. The access token is also retrieved from the session, validated, and added to the GraphQL context whenever an established subscription event "fires". If the access token cannot be validated, the socket is closed.