How can OpenId Connect protect resource server from client impersonation?

Question

I know openId connect can issue an Id token which can be used by the client(relying party) to authenticate the end-user. But how can it be used to protect the resource server from client impersonation? (I think the question is very similar to Client impersonation in OAuth application with implicit authorization)

Say, there's a SPA(android + webAPI), the client(android app) implemented openid connect implicit flow, and will communicate with resource sever(web api) using access token directly. The app redirects the end user to the openid provider firstly, and gains both the id token and access token. However, there's a malicious app which stole the access token and impersonate the client to communicate with the resource server.

How can the resource server know whether the access token is stole or not without id token?

Answer 1

I don't think it can. As you say, OpenID Connect is about authenticating the end-user to the client. It doesn't say anything about authenticating the client to a resource server. The relationship between the client and a resource server is purely OAuth2 and all the resource server can usually do is check whether the access token was issued by the authorization server. Section 10.16 of the OAuth2 spec also discusses how the access token can be misused with the implicit grant.

With the implicit grant there is no guarantee that the client is not malicious. It isnt even authenticated by the authorization server. This differs from the authorization code grant, where the client authenticates to the token endpoint directly. Even then though, with plain OAuth2 the client doesn't authenticate to the resource server, so the resource server doesn't know what client is sending the request.

OAuth2 leaves out how the access token is implemented or validated, so depending on the details, the resource owner may be able to obtain more information from the token about which client requested the it. But with the implicit grant, you don't have any guarantees.

Answer 2

Maybe I am wrong but isn't that the reason for the client secret? The malicious app shouldn't now the client secret and so shouldn't be able to make a successful request to the resource server.