0

I am trying to implement "Login with Google/Apple etc..." on a web platform and I can't wrap my head around how you can trust the response that supposedly comes from the resource server owned by these platforms.

For comparison, when normal username/email and password pair are provided, the correct password is a good enough piece of information to be sure enough that the authentication request was made by the owner of the account.

In the case of OAuth 2.0 with OpenID the only thing that you get is some personal information and an ID, thing which can be known by other platforms with a similar implementation for authentication. Let's say that the database of one of these platforms is compromised, what stops an attacker from doing DNS spoofing or MITM attack and impersonating the resource server and providing me with the same information that the real server would?

In short, how can you trust OpenID when you don't get something that you are sure only you and the resource/authorization server know?

Besides the obvious: SSL/TLS and the JWT signed token?

2
  • Speaking about JWT, I'm not aware of any way to verify that the token is really signed by some party in particular, I understand that it can be verified against tampering, but if I read the JWT's contents and sign it myself, how can another party (besides the ones that have access to the secret) know that the JWT can be trusted?
    – qUneT
    Commented May 9 at 7:52
  • With public-key signatures (which are recommended), anybody can verify the signature with the public key of the Authorization Server. It's not necessary to have access to any secret. With MAC-based signatures, the Authorization Server and the application do need a shared secret. Other parties without access to the secret cannot verify the MAC.
    – Ja1024
    Commented May 9 at 12:45

1 Answer 1

2

After the user has logged in via Google etc., your application receives a signed ID token from the Authorization Server (the Resource Server isn't involved in authentication). According to the specification, the signature must be a JSON Web Signature (JWS), so it has to use either a public-key algorithm or a message authentication code (MAC) algorithm. In the case of a public-key algorithm like RS256 (RSA with SHA-256), the Authorization Server calculates the signature with its private key (which nobody else knows), and your application can verify the signature with the Authorization Server's public key. In the case of a MAC algorithm like HS256 (HMAC with SHA-256), the Authorization Server and your application have a shared secret (which nobody else knows) which is used to both calculate and verify the signature.

In any case, through the JWS signature, you can verify that the ID token has in fact been issued by the Authorization Server. This signature is not just protection against tampering. It proves authorship. Additionally, OpenID uses timestamps and nonces to prevent replay attacks. This means an attacker cannot simply record a token and use it later to pretend they're the Authorization Server.

Of course the signatures depend on the private key or shared secret being secret. If you think the Authorization Server has been compromised, then you obviously cannot trust it to authenticate users for you. Either switch to a different provider -- or don't use OpenID at all, if you're uncomfortable delegating authentication.

2
  • Thank you both for this answer and for the comment, as expected it seems that I have a lot to learn about OpenID and JWT, very useful these resources. I didn't go thorough enough through the materials you provided, but to be honest it still seems a less secure alternative to conventional user-password combination. I will edit/answer my question with my insights after I finish my implementation so others can learn form my experience. Thank you again for taking the time to formulate this answer.
    – qUneT
    Commented May 9 at 20:37
  • I wouldn't say that OpenID is inherently less secure than implementing the authentication yourself. Sure, there's a third party involved, and if they're compromised, this affects your application as well. However, I expect big companies like Google, Apple etc. to have pretty solid security that is hard to beat it terms of hardware, manpower and expertise. But of course it's valid to avoid third-party authentication providers altogether.
    – Ja1024
    Commented May 9 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .