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
We have an existing native login experience on our mobile app and cannot use browser redirects for various reasons. So, we want to mimic the same experience that the Google SDK and Apple SDKs currently support for submitting an ID token to Kratos during login.
It looks like the work for this was done for the Google and Apple providers in #3515. But this does not work for the generic provider, which is what we will be using.
Describe your ideal solution
I plan on implementing ID token verification for the generic provider like what was done for Google and Apple already. The primary difference is that the Issuer URL and JWKS URI will not be hard-coded. The Issuer URL is already in configuration and just needs to be exposed.
The JWKS URI should be available through the gooidc library. I believe that library already derives the JWKS URI when it validates the ID token for the traditional OIDC flow.
There may also be some minor refactoring to the Google and Apple providers to use any changes we make to the generic provider for ID token verification.
Workarounds or alternatives
We considered using browser redirects through the traditional OIDC flow, but that adds the complexity of having to implement Hydra or some other full OAuth2 service.
Version
1.1.0
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Preflight checklist
Ory Network Project
No response
Describe your problem
We have an existing native login experience on our mobile app and cannot use browser redirects for various reasons. So, we want to mimic the same experience that the Google SDK and Apple SDKs currently support for submitting an ID token to Kratos during login.
This is the login that I am referring to:
It looks like the work for this was done for the Google and Apple providers in #3515. But this does not work for the generic provider, which is what we will be using.
Describe your ideal solution
I plan on implementing ID token verification for the generic provider like what was done for Google and Apple already. The primary difference is that the Issuer URL and JWKS URI will not be hard-coded. The Issuer URL is already in configuration and just needs to be exposed.
The JWKS URI should be available through the
gooidc
library. I believe that library already derives the JWKS URI when it validates the ID token for the traditional OIDC flow.There may also be some minor refactoring to the Google and Apple providers to use any changes we make to the generic provider for ID token verification.
Workarounds or alternatives
We considered using browser redirects through the traditional OIDC flow, but that adds the complexity of having to implement Hydra or some other full OAuth2 service.
Version
1.1.0
Additional Context
No response
The text was updated successfully, but these errors were encountered: