New Feature / Enhancement Checklist
Current Limitation
The LINE auth adapter currently supports the server-side code + redirect_uri exchange flow, and the legacy insecure id + access_token fallback when insecure auth is enabled.
It does not support the common OpenID Connect pattern where a trusted client or separate auth service obtains a LINE id_token, and Parse Server only validates that token before linking/logging in the user.
This differs from providers such as Google / Apple-style auth flows where a secure client-provided token can be validated directly by Parse Server.
Feature / Enhancement Description
Add secure LINE OpenID Connect id_token validation to the LINE auth adapter.
Expected behavior:
- accept LINE authData containing
id_token
- verify JWT signature against LINE signing keys / supported algorithms
- validate issuer, audience/client ID, subject, and nonce when provided
- normalize LINE
sub / userId into Parse authData id
- keep the existing
code + redirect_uri flow working
- keep the legacy insecure auth fallback only when explicitly enabled
A PR implementing this is already open: #10436
Example Use Case
An app uses LINE Login through a separate frontend or auth service. That service obtains a LINE OpenID Connect id_token. Parse Server should not need the LINE client secret or perform the authorization-code exchange itself; it should only validate the resulting LINE identity token and link/login the user.
This is useful when authentication is centralized outside Parse Server, but Parse Server remains the user/account backend.
Alternatives / Workarounds
For this flow, only via enabling the legacy insecure auth.
3rd Party References
- General LINE Login / OpenID Connect ID token validation
I've opened a PR for this at #10436
New Feature / Enhancement Checklist
Current Limitation
The LINE auth adapter currently supports the server-side
code + redirect_uriexchange flow, and the legacy insecureid + access_tokenfallback when insecure auth is enabled.It does not support the common OpenID Connect pattern where a trusted client or separate auth service obtains a LINE
id_token, and Parse Server only validates that token before linking/logging in the user.This differs from providers such as Google / Apple-style auth flows where a secure client-provided token can be validated directly by Parse Server.
Feature / Enhancement Description
Add secure LINE OpenID Connect
id_tokenvalidation to the LINE auth adapter.Expected behavior:
id_tokensub/userIdinto Parse authDataidcode + redirect_uriflow workingA PR implementing this is already open: #10436
Example Use Case
An app uses LINE Login through a separate frontend or auth service. That service obtains a LINE OpenID Connect
id_token. Parse Server should not need the LINE client secret or perform the authorization-code exchange itself; it should only validate the resulting LINE identity token and link/login the user.This is useful when authentication is centralized outside Parse Server, but Parse Server remains the user/account backend.
Alternatives / Workarounds
For this flow, only via enabling the legacy insecure auth.
3rd Party References
I've opened a PR for this at #10436