App client secret in moblie app?

[eerimoq]

Is it safe to store the client secret in a mobile app, essentially leaking it? If not, how do a user login from an app directly to Kick?

[ACPixel]

Generally, it is not safe to store secrets in a mobile app because they can be extracted.

Currently, the Kick OAuth system only supports the Authorization Grant flow, which requires a secret. To securely implement this in a mobile app, you would need the user to authenticate in an in-app browser using OAuth with your own server.

In the future, I anticipate that Kick will add other OAuth flow types that do not require a secret, such as the Implicit Grant flow.

However, for now, if you want to authenticate with a mobile app without leaking your client secret, you will have to use your own server as an intermediary.

[eerimoq]

Thanks, but why do the docs link to OAuth 2.0 Code Grant flow with PKCE, which describes how to authenticate without a client secret as I understand it?

[ACPixel]

That link is worded in an obnoxiously confusing way haha. But it is describing the code flow which requires a secret.

The top few points there are just it telling you situations that the flow is not designed for.

[eerimoq]

You sure about that? Looks like the Authorization Code Flow is the one with a secret.

But what do I know. Authentication is confusing =)

[ACPixel]

Authentication is indeed confusing. The docs link to the Authorization Code Flow, with PKCE which is ultimately just an extra layer of security to make sure the same system started and ended the oauth request to my understanding.

The only flows that doesn't require a secret to my knowledge are "implicit" grant flows.

(definitely could be wrong here but I've been doing OAuth for about 10 years now so at this point I'd hope I know what I'm talking about maybe lol)

[eerimoq]

Haha yeah for Twitch my app uses the implicit grant flow

[laurencee]

Something I don't understand here is there's an /oauth/authorize endpoint to get a code but then the only way to use that code is /oauth/token that also requires the client secret, which completely defeats the point since now you have to expose the secret.

If I'm understanding Auth0's docs, the /token endpoint is meant to just take the auth code and code verifier to give back an access/id token as described in the docs kick links to (see steps 6 -> 9).

---

TLDR; /oauth/token shouldn't be requiring a client_secret if I understand this correctly. @IAmTheHouse-X correct me if I'm wrong here, auth flow is always a bit confusing haha.

I'm working off the info available here:

• https://docs.kick.com/getting-started/generating-tokens-oauth2-flow#token-endpoint
• https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow

[GodWasaProgrammer]

Something I don't understand here is there's an /oauth/authorize endpoint to get a code but then the only way to use that code is /oauth/token that also requires the client secret, which completely defeats the point since now you have to expose the secret.

If I'm understanding Auth0's docs, the /token endpoint is meant to just take the auth code and code verifier to give back an access/id token as described in the docs kick links to (see steps 6 -> 9).

TLDR; /oauth/token shouldn't be requiring a client_secret if I understand this correctly. @IAmTheHouse-X correct me if I'm wrong here, auth flow is always a bit confusing haha.

I'm working off the info available here:

• https://docs.kick.com/getting-started/generating-tokens-oauth2-flow#token-endpoint
• https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow

No you are very much correct, this is how it is supposed to be.

However Kick is not alone in this, for example google only allows leaving out Client Secrets for UWP apps, which requires a microsoft store id. However, since they dont doublecheck the microsoft store id, they allow you to use PKCE flow without a client secret like this.