feat: Add parseIdToken utility to public API#1537
Conversation
|
Hi @opfeffer |
opfeffer
force-pushed
the
feat/export-parse-id-token
branch
from
dd955e8 to
bf66d4e
Compare
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughAdds a new public utility ChangesparseIdToken Utility
🎯 2 (Simple) | ⏱️ ~10 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Exposes a public `parseIdToken(idToken)` utility that returns a `User` object by decoding a JWT ID token locally. This provides the same user-parsing behavior that Auth0Provider uses internally, for consumers managing auth state directly via the Auth0 class. Closes auth0#1536
opfeffer
force-pushed
the
feat/export-parse-id-token
branch
from
bf66d4e to
b2a19f9
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
EXAMPLES.md (1)
4-15:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate the Authentication API TOC to include the new subsection.
The new “Parse user profile from an ID token locally” section is present, but it isn’t linked from the Authentication API subsection list at the top.
Doc TOC patch
- [Authentication API](`#authentication-api`) - [Login with Password Realm Grant](`#login-with-password-realm-grant`) - [Get user information using user's access_token](`#get-user-information-using-users-access_token`) + - [Parse user profile from an ID token locally](`#parse-user-profile-from-an-id-token-locally`) - [Getting new access token with refresh token](`#getting-new-access-token-with-refresh-token`)Also applies to: 140-154
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@EXAMPLES.md` around lines 4 - 15, Add a TOC link for the new subsection "Parse user profile from an ID token locally" to the Authentication API list in EXAMPLES.md by inserting a bullet like "- [Parse user profile from an ID token locally](`#parse-user-profile-from-an-id-token-locally`)" into the existing Authentication API subsection list (the list that contains entries such as "Login with Password Realm Grant" and "Using Custom Headers"); ensure the link text matches the new section header exactly so it anchors correctly and update the other duplicate TOC area (lines ~140-154) the same way.
🧹 Nitpick comments (1)
src/core/utils/__tests__/parseIdToken.spec.ts (1)
13-61: ⚡ Quick winAdd an explicit custom-claims pass-through assertion.
Current tests cover standard mapping, protocol filtering, and missing
sub, but not the documented custom-claim behavior. A small test for one namespaced custom claim (e.g.https://example.com/role) would lock the public contract.Suggested test addition
describe('parseIdToken', () => { @@ it('should throw if the token is missing the sub claim', () => { @@ }); + + it('should keep custom claims unchanged', () => { + mockJwtDecode.mockReturnValue({ + sub: 'auth0|123', + 'https://example.com/role': 'admin', + }); + + const user = parseIdToken('mock-id-token'); + expect((user as any)['https://example.com/role']).toBe('admin'); + }); });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/utils/__tests__/parseIdToken.spec.ts` around lines 13 - 61, Add a test to parseIdToken.spec.ts that ensures namespaced custom claims are passed through: mock jwtDecode to return a namespaced claim like "https://example.com/role": "admin" alongside sub, call parseIdToken('mock-id-token') and assert the returned user object contains that exact namespaced claim (e.g. (user as any)['https://example.com/role'] === 'admin'), keeping existing expectations for sub; this validates parseIdToken's custom-claim pass-through behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@EXAMPLES.md`:
- Around line 4-15: Add a TOC link for the new subsection "Parse user profile
from an ID token locally" to the Authentication API list in EXAMPLES.md by
inserting a bullet like "- [Parse user profile from an ID token
locally](`#parse-user-profile-from-an-id-token-locally`)" into the existing
Authentication API subsection list (the list that contains entries such as
"Login with Password Realm Grant" and "Using Custom Headers"); ensure the link
text matches the new section header exactly so it anchors correctly and update
the other duplicate TOC area (lines ~140-154) the same way.
---
Nitpick comments:
In `@src/core/utils/__tests__/parseIdToken.spec.ts`:
- Around line 13-61: Add a test to parseIdToken.spec.ts that ensures namespaced
custom claims are passed through: mock jwtDecode to return a namespaced claim
like "https://example.com/role": "admin" alongside sub, call
parseIdToken('mock-id-token') and assert the returned user object contains that
exact namespaced claim (e.g. (user as any)['https://example.com/role'] ===
'admin'), keeping existing expectations for sub; this validates parseIdToken's
custom-claim pass-through behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 0debebe9-2ab5-4794-bb1f-ddbf8b85a2ae
📒 Files selected for processing (5)
EXAMPLES.mdsrc/core/utils/__tests__/parseIdToken.spec.tssrc/core/utils/index.tssrc/core/utils/parseIdToken.tssrc/index.ts
My bad for not properly signing the first time. Rebased my PR and signed my commit. Ready for another look @subhankarmaiti |
2 participants
Changes
Adds a public
parseIdToken(idToken: string): Userutility function that decodes a JWT ID token locally and returns aUserobject with standard OIDC profile claims (camelCased) and any custom claims.This is a purely additive change — no existing functionality is modified. It introduces a new export only, so the risk surface is minimal.
parseIdToken(fromsrc/core/utils/parseIdToken.ts)src/index.tsUsage:
Auth0Provideralready uses this parsing logic internally viaAuth0User.fromIdToken(). This exposes the same behavior for consumers managing auth state directly via theAuth0class, without requiring a network round-trip to/userinfo.References
Testing
New unit tests in
src/core/utils/__tests__/parseIdToken.spec.tscovering:Standard OIDC claims are decoded and camelCased
Protocol claims (iss, aud, exp, etc.) are excluded
Missing
subclaim throws an errorThis change adds unit test coverage
This change has been tested on the latest version of the platform/language or why not
Checklist
Closes #1536
Summary by CodeRabbit
New Features
Documentation
Tests