LINE Profile API response format mismatch with node-openid-client

[ThangHuuVu]

I asked the question on LINE Developer Community: https://www.line-community.me/en/question/615fce7369e9a54065f239cd/profile-api-response-format-mismatch-with-nodeopenidclient
Problem: Cannot connect to LINE profile API using node-openid-client.

Pre condition, Condition to reproduce

• Create a LINE Login Channel
• Use LINE profile API v2 with openid-client latest version.

Issue/ Error Message details

According to this documentation:

The LINE Platform issues ID tokens compliant with the OpenID Connect (opens new window) specification, allowing you to securely obtain user profile information (user ID, display name, profile picture, email address) from the LINE Platform.

The example response of API is as follow (according to this documentation):

{
  "userId":"U4af4980629...",
  "displayName":"Brown",
  "pictureUrl":"https://profile.line-scdn.net/abcdefghijklmn",
  "statusMessage":"Hello, LINE!"
}

While as the node-openid-client docs states, it requires a check for userinfo.sub:

Fetches the OIDC userinfo response with the provided Access Token. Also handles signed and/or encrypted userinfo responses. When TokenSet is provided as an argument the userinfo sub property will also be checked to match the on in the TokenSet's ID Token.

Which is obviously missing from the response. My question is whether should the expected response should be something like:

{
  "userId":"U4af4980629...",
  "sub":"U4af4980629...", //same with userId
  "displayName":"Brown",
  "pictureUrl":"https://profile.line-scdn.net/abcdefghijklmn",
  "statusMessage":"Hello, LINE!"
}

or a modification in this repository is needed? If I change the source code of openid-client to check with userId instead of sub, then it works. I don't know if this change should be on LINE API or openid-client, please give your advice.
The check: https://github.com/panva/node-openid-client/blob/3ae206dfc78c02134aa87a07f693052c637cab84/lib/client.js#L1159

[panva]

openid-client exhibits the correct and expected behaviour. sub is a required attribute in the userinfo response when openid is used.

It is also required that the value returned be the same as in an issued ID Token which is the exact check you run into. This is also behaviour checked for by the conformance suite used to certify this software's conformance to the openid connect protocol.

But the question is whether that endpoint truly is meant to be a userinfo endpoint in the openid connect protocol sense.

[ThangHuuVu]

@panva thank you for confirmation. I am actually using next-auth in my setup. Therefore, I will continue the discussion there. It seems like GET https://api.line.me/v2/profile configured as default in next-auth is not the OIDC userinfo endpoint. The correct one is POST https://api.line.me/oauth2/v2.1/verify. https://developers.line.biz/en/reference/line-login/#verify-id-token

[panva]

errm, that's not openid either. that's a joke API, right?

[ThangHuuVu]

It's not? The response is like this:

{
    "iss": "https://access.line.me",
    "sub": "U1234567890abcdef1234567890abcdef",
    "aud": "1234567890",
    "exp": 1504169092,
    "iat": 1504263657,
    "nonce": "0987654asdf",
    "amr": [
        "pwd",
        "linesso",
        "lineqr"
    ],
    "name": "Taro Line",
    "picture": "https://sample_line.me/aBcdefg123456",
    "email": "taro.line@example.com"
}

That's not a joke API, thats a production API right there

[panva]

You're missing my point. That is not an OpenID Connect API, it is not the userinfo endpoint (LINE has none, see https://access.line.me/.well-known/openid-configuration). And it is ridiculous to think I need to call an API to parse and verify a JWT for me when OpenID RP already does that for you locally.

[ThangHuuVu]

Ok, I think I get it know. So Line just doesn't provide userinfo endpoint for more granular control; they only provide OAuth via this /.well-known option. Thanks for the explanation, I'm kind of a newbie to this OpenID concept 😄.
About the API above, it is said in the docs:

It's possible for an attacker to spoof an ID token. Use this call to verify that a received ID token is authentic, meaning you can use it to obtain the user's profile information and email.

Is there a scenario where using OpenID RP is not possible? In that case, the API can be useful.

[panva]

There's nothing that API can do that you can't do locally with information given to you via the well known discovery.