Authentication cookie set up mechanism

[skabashnyuk]

Description

We would like to set up a generic way for services that are required authentication to get a token and setup it as a cookie. Some services like Thiea are not designed in a way where authentication token can be easily added as header or query parameter. So making some generic approach to get this token can be a good idea.

Proposed flow.

1. GET http://some-ide-service:8533/api/

• JWTProxy checks token and if:
  • valid token is present then JWTProxy just proxies request to target URL;
  • token is missing or invalid then JWTProxy redirects request to wsmaster/loader.html?workspaceId=werjo292390923&redirectUrl=http%3A%2F%2Fsome-ide-service%3A8533%2Fapi%2F. Go to next step;

2. GET wsmaster/loader.html?workspaceId=werjo292390923&redirectUrl=http%3A%2F%2Fsome-ide-service%3A8533%2Fapi%2F

• page is protected with authentification with keycloak.js;
• page gets the configuration of workspace with id = werjo292390923 and check that it has a server with host specified in redirect url query parameter some-ide-service:8533;
• page gets the ws-token from configuration and do request to http://some-ide-service:8533/authenticate where token will be set as Authorization header;
  • JwtProxy processes this request and sends `Set-Cookie: access_token={TOKEN_HERE}; header in response;
• page redirects to url that is specified in redirectUrl query parameter;

3. Now JWT Proxy should authenticate request with token from cookie and proxy request to target URL http://some-ide-service:8533/api/

[garagatyi]

Can you elaborate why auth sidecar can't verify everything needed using auth API instead of redirecting to the master?

[skabashnyuk]

It can verify token but it can't set it for you. The goal of this process is to set up a cookie with a token that can be verified with auth sidecar.

[garagatyi]

I see, thank you for the clarification.

[sleshchenko]

I investigated if this approach has common secure issues, so

CSRF

There are three possible ways to authenticate requests:

1. Provide token in query parameters;
2. Provide token in header Authorization;
3. Save token in the corresponding cookie.

For 1st and 2nd options, CSRF is not actual since client should provide a token explicitly (form won't be submitted with token automatically by browser because there is no the corresponding cookie).

3rd option should be used carefully.
If server doesn't support any modification requests which can't be triggered by form then this option can be used and there are no any risk to be attacked with CSRF.
Otherwise, server developer should implement protection with CSRF tokens himself if he need this way of token providing.
We should not allow to use this token in cookie by default, and maybe configure it in server configuration, for example for Theia server which doesn't have any modification REST API methods. The corresponding comment is added into the issue description.

XSS

We can not garuantee that servers are protected from XSS attacks because it really depends on server implementation. The only thing that can be improved in current proposed implementation - is set HttOnly token cookie on server side to avoid possibility to stole token by injection scripts into pages.
Update: Schema described in the issue description is updated to use http only cookie to store token

[sleshchenko]

It makes sense to allows cookie authorization for all servers for time being and implement such restriction in a separate issue since JWTProxy is disabled in master branch.
Update: Here is an separate issue for that #10481

[sleshchenko]

Update:

1. Renamed wsId query parameter to workspaceId, to make it clearer that it is an identifier of workspace but not WebSocket or something else.
2. JwtProxy/authorize method expects token to be sent in Authorization request header instead of query parameters.