authgear / authgear/authgear-server
Investigate loading state handling of SDKs
- Dominant language
- Go
- Stars
- 2k
- Forks
- 125
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 32
Description
In SDKs, we open hosted web UI using system API (e.g. Android custom tabs, iOS ASWebAuthenticationSession). After showing the web UI, the SDK would receive an authorization code, which SDK would need to call API to exchange for a token. During the API call, often a loading state would be desired to indicate progress.
We should check if SDK need to handle responsibility of showing loading state, or how should the SDK users handle the loading state.
Most of the auth softwares in the market falls in these cases:
- Does not have native SDK (for example, SDK for web only)
- Does not provide hosted web UI (for example, accepting email & password directly in native UI and call API with them)
- Use system API to display hosted web UI without handling any loading state.
It seems no other auth SDK provides/handles display of loading state directly (at least in official demo/example apps).
Contributor guide
Research direction
Start by reviewing the Android custom tabs and iOS ASWebAuthenticationSession flows described in the issue, focusing on the period after the hosted UI returns an authorization code and before token exchange completes. Compare the behavior with official demo or example apps and document a clear decision for whether SDKs or SDK users own the loading state.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, ios
- Domain
- authentication, mobile-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100