You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some IdPs (Google Public OIDC), their access tokens are not externally verifiable nor intended to be inspected. Therefore, the only token that can relied on is the ID token. In general, access tokens should be used, but when we cannot, sharing the ID token between Ziti SDK/Clients and Ziti controllers should be supported.
Support selecting which token to use via the Management API on create/update/patch
Support reporting which token to use via the Management API on list/detail
Support reporting which token to use via the Client API on list/detail
Token fields to be supported: ACCESS, ID
Default existing External JWT signers to ACCESS
Additional Information:
Another option is making the OpenZiti controller a relying party, allowing the configuration of a client_id/client_secret. However, it involves maintaining and defending against replay and novel attacks from separate user scopes, which increases the controller's attack surface with little benefit over using code flow + PKCE on the user device.
The text was updated successfully, but these errors were encountered:
- adds targetToken of values ACCESS, ID for management API CRUD
- adds targetToken to client API reads
- adds --target-token to external jwt signers CLI
- updates/adds tests
- adds targetToken of values ACCESS, ID for management API CRUD
- adds targetToken to client API reads
- adds --target-token to external jwt signers CLI
- updates/adds tests
For some IdPs (Google Public OIDC), their access tokens are not externally verifiable nor intended to be inspected. Therefore, the only token that can relied on is the ID token. In general, access tokens should be used, but when we cannot, sharing the ID token between Ziti SDK/Clients and Ziti controllers should be supported.
Additional Information:
Another option is making the OpenZiti controller a relying party, allowing the configuration of a client_id/client_secret. However, it involves maintaining and defending against replay and novel attacks from separate user scopes, which increases the controller's attack surface with little benefit over using code flow + PKCE on the user device.
The text was updated successfully, but these errors were encountered: