Currently the oauth flow is basically just Auth Code Grant which requires the client secret (in this case, the certificate, in order to generate the JWT) to be stored wherever that code executes.
In the case of a mobile app (like an Android app) it's considered a bad security practice to ship your client secret in your code. Usually Oauth provides an implicit flow for 'public' clients where there is no guarantee of privacy for storing the oauth secret. The access tokens provided are usually short lived in the implicit flow, for this reason.
I understand the intent here is probably to have other platforms use a web backend for retrieving the access token securely, however in practice this isn't what developers are all going to do, and there's really no easy way to prevent them from doing this. It would be much safer to provide an implicit oauth flow for this use case.
On Jun 24, 2019, Redth wrote:
> In the case of a mobile app (like an Android app) it's considered a bad security practice to ship your client secret in your code. Usually Oauth provides an implicit flow for 'public' clients where there is no guarantee of privacy for storing the oauth secret. The access tokens provided are usually short lived in the implicit flow, for this reason.
To add Sign in with Apple to apps that don’t have access to the Sign in with Apple JS framework, you must manually control the sign-in request as described in "Incorporating Sign in with Apple into Other Platforms". The client-side authorization request is an HTTP GET to the `/auth/authorize` endpoint, and requires the following query parameters—
- `client_id`
- `redirect_uri`
- `response_type`
- `scope`
- `response_mode`
- `state`
- `nonce`
An example authoriazation request URL is—
A client secret (JWT) is not required for authorization requests, but is required for validating the authorization grant code sent to the client application to validate a session with a server backend as described in "Generate and validate tokens". The server-side authorization request is an HTTP POST to the `/auth/token` endpoint, and requires the following query parameters—
- `client_id`
- `client_secret` (JWT)
- `code`
- `grant_type`
- `redirect_uri` (if provided to the `/auth/authorize` request above)
For PKCE, I'd suggest submitting an enhancement request via Feedback Assistant.
