Harbor Access / 06 / PRACTICE GUIDE

SSO, OAuth/OIDC and token trust

Distinguish reading JWT content from validating it. Review issuer, audience, time, redirects and consent in a complete trust chain.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

EVIDENCE REVIEW DESK

Move from observations to decisions.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

The JWT is readable / Incomplete decision

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s => s.jwtDecoded === true

Readable claims establish no signature, issuer, audience or time validation. This Boolean evidence model cannot replace actual cryptographic implementation; production needs a trusted library.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

Define the boundary of SSO

SSO provides a sign-in experience across applications; it does not guarantee identical authorization and session policies. OAuth is an authorization framework, while OIDC adds an identity layer. ID tokens and API access tokens have different purposes. Harbor inventories the identity provider, application owner, accepted tenant/issuer and data scope separately. This lesson establishes no SSO connection. A successful connection indicator does not prove that every application validates the correct token and enforces object permissions. Review each relying application’s trust boundary rather than treating federation as universal access approval.

02 / EXPLANATION

Decoding is not validation

Readable JWT claims are not automatically trustworthy roles. Appropriate signature, algorithm/key selection, expected issuer and audience, time conditions and protocol-dependent checks are needed. Design trusted metadata retrieval and key rollover separately. Boolean fields here assert that evidence exists; they perform no cryptographic validation. The local access desk neither accepts nor decodes JWTs. Learners explain which application evidence is needed for each check rather than fabricating a signature-validation result. Token content should not be pasted into a public learning page or an untrusted external decoding service.

03 / EXPLANATION

Redirects and response binding

RFC 9700 updates OAuth security practice. Exact redirect matching, appropriate PKCE and request/response binding matter, with details depending on protocol and client type. OIDC nonce and OAuth state are not interchangeable concepts. Harbor includes no working exploit or token exchange; its review plan defines negative cases such as invalid redirects and mismatched context. Real applications should use maintained protocol libraries and the relevant official validation rules. Passing the educational evidence model establishes neither correct protocol implementation nor resistance to every OAuth attack.

04 / EXPLANATION

Application consent and scope

Application registration does not establish that every permission is needed. Delegated and application-only access have different risk implications. Record tenant, data source, permission, consent authority and periodic review. Removing unnecessary scope involves existing consent and token behavior, not just hiding an app tile. Harbor workpapers capture the consent owner, business rationale and validation needed after revocation. This package consents to no real third-party application and changes no SSO configuration. Treat consent as a governed authorization decision rather than an incidental registration checkbox.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Identity and access scopeMarkdown · ENPermission and negative-test planMarkdown · ENDecision, grant and evidence gapMarkdown · ENEnforcement and outcome verificationMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.