TL;DR: A Flet tutorial shows how to wire OAuth 2.0, OIDC, magic links, social login, and Okta-based SSO into a cross-platform app, then persists tokens for repeat sign-ins, according to Descope. The security takeaway is that federation and token handling are identity controls, not just developer convenience, and they deserve lifecycle governance.
At a glance
What this is: This is a developer tutorial for adding authentication, SSO, and persistent sign-in to a Flet app, with the key finding that OAuth/OIDC token handling becomes part of the app’s identity control plane.
Why it matters: It matters because IAM and security teams need to treat app-level login flows, token storage, and federation settings as governed identity surfaces, especially when developers are implementing them directly in the product.
👉 Read Descope's tutorial on authentication and SSO for Flet apps
Context
Application authentication is no longer limited to the front door. When a product team builds login, token persistence, and single sign-on into the app itself, those choices become part of the organisation’s identity architecture and its control assumptions. In this case, the primary identity concern is human IAM, because the tutorial is about end-user sign-in, federation, and session handling.
Flet applications expose the same governance questions seen in any federated app: who authenticates users, where tokens are stored, how logout is enforced, and what happens when a user returns to the app later. The relevant control plane includes OAuth 2.0, OpenID Connect, and the operational handling of client-side secrets and cached tokens.
Key questions
Q: How should teams govern authentication across web, mobile, and desktop apps?
A: Treat each surface as its own application context even when the same users and organisations are shared. Separate client IDs, redirect URIs, and session policies keep the experience consistent while allowing security controls to differ by risk. The important part is maintaining one identity source of truth so lifecycle events and account state stay aligned across all apps.
Q: When does client-side token storage become a security problem?
A: It becomes a problem when cached tokens can survive beyond the intended session, move across devices, or remain valid after a user should no longer have access. Encryption helps, but governance still needs deletion on logout, revocation handling, and a clear decision on whether local persistence is acceptable for the application’s risk profile.
Q: Why does SSO improve control in B2B applications?
A: SSO reduces duplicate accounts and centralises authentication at the corporate IdP, which makes access policy easier to enforce and audit. The benefit only holds if provisioning and deprovisioning are accurate, because the application inherits the source directory’s account state and attribute quality.
Q: What should IAM teams check before approving a custom OAuth integration?
A: Check that the provider settings are correct, the token exchange is limited to the intended scopes, the userinfo mapping is stable, and session termination is enforced. The app should also be able to reject stale or missing tokens cleanly without creating a bypass path for unauthenticated users.
Technical breakdown
OAuth 2.0 and OIDC in a desktop-style app
The tutorial uses the OAuth 2.0 authorization code flow and OIDC to let Flet delegate authentication to an external identity provider. OAuth handles delegated authorisation, while OIDC adds identity claims such as user profile details. The app must configure a client ID, client secret, authorization endpoint, token endpoint, userinfo endpoint, redirect URI, scopes, and a user ID mapping. That turns the application into a federated relying party rather than a standalone credential store.
Practical implication: review redirect URIs, scopes, and userinfo handling as part of application onboarding and change control.
Token persistence and local session state
The tutorial stores an encrypted token in client storage so the app can restore a user session without forcing a fresh login every time. That improves usability, but it also creates a local trust boundary that needs governance. The encryption step reduces exposure of the stored token, yet the application still depends on the secrecy of the key, the integrity of client storage, and the app’s logout logic to clear state when access ends.
Practical implication: treat client-side token persistence as a controlled session mechanism, not a convenience feature.
SSO as an identity control for B2B apps
The SSO setup links the Flet app to an external identity provider such as Okta so users can authenticate with existing enterprise credentials. That shifts trust to the upstream IdP and makes federation policy part of the app’s security design. In B2B environments, this reduces account duplication and password sprawl, but it also means the app must respect provisioning, revocation, and identity attribute consistency from the source directory.
Practical implication: align app onboarding and offboarding with the upstream IdP lifecycle, not with local app-only records.
NHI Mgmt Group analysis
Federated authentication in app code is an identity governance decision, not just an implementation detail. The tutorial shows that developers are directly configuring OAuth endpoints, token storage, and logout behaviour inside the application. That pushes identity control into product code, where misconfiguration can outlive design intent. Practitioners should treat this as a governed integration pattern, with clear ownership between IAM, application engineering, and security.
Client-side token persistence creates a governance boundary that many teams underestimate. Encrypting the token before saving it to client storage reduces obvious exposure, but it does not remove the fact that access is being cached on the device. The real question is how the organisation governs reuse, logout, and token invalidation across devices and sessions. That is a lifecycle issue, not a front-end convenience issue.
SSO only improves security when the upstream identity lifecycle is clean. The tutorial’s B2B framing assumes the external IdP is the source of truth for authentication and account state. If provisioning, deprovisioning, or attribute updates lag behind reality, the app inherits those weaknesses immediately. Centralised sign-in without lifecycle discipline is just centralised risk.
Application authentication is now part of the broader IAM operating model. Teams can no longer separate “product login” from enterprise identity controls when apps use OIDC, stored tokens, and third-party IdPs. The discipline required here spans access policy, session handling, and revocation semantics. That means IAM teams need to review developer-built auth flows with the same scrutiny they apply to other identity integrations.
What this signals
As more product teams build federated login into their own applications, IAM programmes need a repeatable review model for OAuth, OIDC, and token persistence. The risk is not only weak authentication, but unmanaged identity behaviour embedded in application code.
The practical shift is toward treating app authentication as part of the identity inventory. That means tracking where tokens are stored, which IdPs are trusted, and how offboarding is enforced when a user’s upstream account changes.
For practitioners
- Govern redirect and scope configuration Verify every redirect URI, scope set, and user identity mapping before an app is promoted beyond development. Keep the configuration under change control so authentication behaviour cannot drift silently across environments.
- Treat token storage as a governed session control Define whether cached tokens may live on the client, how they are encrypted, and when they must be deleted. Make logout enforce storage removal and test that behaviour across browser restarts and device reuse.
- Align app access with IdP lifecycle events Ensure app access follows upstream provisioning and revocation so users do not keep local access after their identity is disabled in the source directory. Offboarding should invalidate app sessions, not just directory entries.
- Review developer-authenticated apps as identity assets Add application login flows to IAM review, architecture review, and audit scope. Any app that handles federation, tokens, or SSO should be catalogued as part of the identity estate, not treated as a standalone feature.
Key takeaways
- Application login flows are identity controls, so IAM teams should govern them as part of the wider access architecture.
- Token persistence improves convenience but creates a session governance problem if logout, revocation, and client storage are not tightly controlled.
- SSO only strengthens security when the upstream identity lifecycle is accurate, complete, and consistently enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C | The tutorial uses federated sign-in and OIDC-based identity assertions. |
| NIST CSF 2.0 | PR.AC-1 | The article is about controlling application access through trusted identity sources. |
| NIST Zero Trust (SP 800-207) | The app relies on continuous trust decisions around federated access and session state. | |
| NIST SP 800-53 Rev 5 | IA-2 | The post focuses on user authentication and federation setup. |
Use zero trust principles to review every session and token rather than assuming prior login remains valid.
Key terms
- Federated Authentication: Federated authentication lets one organisation or platform accept a login performed by another trusted identity system. The application no longer verifies the user directly. Instead, it consumes signed claims or assertions, which makes trust relationships, certificates, and attribute mapping part of the security boundary.
- OpenID Connect: OpenID Connect is an identity layer built on OAuth 2.0 that lets applications authenticate users with compact tokens and standardised key discovery. It is widely used for modern web, mobile, and API-driven systems because it reduces integration overhead compared with older federation patterns.
- Token Persistence: Token persistence is the retention of access or refresh tokens beyond the immediate task that justified them. In browser-based integrations, it increases the chance of unauthorized reuse, complicates revocation, and creates a governance problem because the credential outlives the user’s intent.
What's in the full article
Descope's full tutorial covers the operational detail this post intentionally leaves for the source:
- Step-by-step Flet code changes for wiring a custom OAuth provider into the app
- Exact environment variables and callback settings used to connect the sign-in flow
- Implementation detail for encrypting, storing, and removing session tokens on the client
- Profile-view code that displays authenticated user attributes after successful login
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 16, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
