Accept OAuth token instead of password hash

[Brutus5000]

There should be only one system responsible for authentication and that is the API.
Instead of sending the hashed password to the server, the client should fetch a token from the API (which it does anyway) and send it to the server.
This would also improve client security, as a token can be stored rather than a hashed password.

Best case would be to do it in 2 steps: Add an additional command for Oauth login with parallel usage, then disable direct login.

[Askaholic]

I like the idea of doing authentication all in one place (namely the API) but wouldn't this be moving in the direction of a high availability API? If the server relies on the API for authentication, then if the API goes down, you can't play FAF, unless you were already logged in before the API went down.

I thought this was something you wanted to avoid.

[Brutus5000]

Yes and no. What I want to avoid is losing data if the api is not available (coupling services synchronously) .
The client already has a dependency to the API for the vault etc.

Also that depends on the implementation of the token fetching. As long as the client has a valid token it does not need to query a new one for login. If we make tokens life long enough this would be only a corner case.

[Askaholic]

Even if the client has a valid token, if the API is down, the server has no way of verifying that the token is valid so it will still not be able to authenticate new users.

But yes, if all we're doing is authentication, then the API going down will not cause data loss. If this is the only concern then I'm all for moving authentication to the API. Having authentication all in one place will make it easier to switch to a different hashing implementation. Plus, API communication is encrypted via TLS.

[Brutus5000]

The point of OAuth tokens is that you do not need to ask the original server. if you can validate the signature of the token you believe everything it claims.

[Askaholic]

Wont you need the API's secret key in order to verify the token? I'm trying to read the API code but it is unclear what algorithm the macSigner is using. I'm assuming HMAC with sha256 as that's the default on https://jwt.io/

[Brutus5000]

You would configure the secret as an environment variable (or file if you go for private/public key files)

[Askaholic]

Yes I know how to configure application secrets, that was not the question. Adding the API secret key to the server means the API secret is not quite as secret any more and gives the server the ability to create valid API tokens. Regardless of whether or not it actually does this, it has the ability to, and therefore you can no longer be completely sure that valid tokens have actually been signed by the API and not one of the other entities out there that knows the secret key.

Sharing secret keys across multiple apps for the purpose of validating messages seems sketchy to me. I think the better solution would be to use use one of the asymmetric variants of JWT. That way the server will only need to know the API's public key and it can still verify that the token was signed by the API without introducing any additional security risks.

[Brutus5000]

Ok. Yes, that is correct. This could be improved.

[Rackover]

You can not play FAF if the API is down, in any way
Because the client relies on the API to get both the game files and (let's say the user already have the files) the gamemodes, and both are needed to host a game.
So API is already mandatory to play, there's no point avoiding to make auth go via API.

[Brutus5000]

API side is in progress: FAForever/faf-java-api#323