docs: OidcClientAuthentication.clientSecretPost only choice for Flutter Web - Security Question

[redsk]

Description

In packages/oidc/example/lib/app_state.dart two OidcUserManager's are created,

• one with clientCredentials: const OidcClientAuthentication.none
• one with clientCredentials: const OidcClientAuthentication.clientSecretPost

Now for a Flutter web app that wants to authenticate using Google Sign In, only the one with clientSecretPost seems to work. When creating a OAuth client ID only the web based one can be applied as it's the only one supporting custom redirects.

Now, isn't it a security issue to store the clientSecret in the Flutter Web app @ahmednfwela ?

[ahmednfwela]

@redsk
no it isn't a security risk since google doesn't consider the client_secret really a "secret" for web, you can think of it as part of the client_id.

another alternative is to use implicit auth.

[ahmednfwela]

also refer to google's own documentation:
https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow

[redsk]

Are you sure about sharing client_secret? https://stackoverflow.com/questions/66214809/is-it-safe-to-distribute-google-api-credentials-with-apps https://developers.google.com/identity/protocols/oauth2/native-app If this is the case then the implicit auth seems to be the only option. Maybe it should be stated in the doc?

…

On Tue, 31 Oct 2023, 04:05 Ahmed Fwela, ***@***.***> wrote: @redsk <https://github.com/redsk> no it isn't a security risk since google doesn't consider the client_secret really a "secret" for web, you can think of it as part of the client_id. another alternative is to use implicit auth. — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA72VELY4HK7QAD55D4W5OLYCBTH5AVCNFSM6AAAAAA6W6YFJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWGM3DKMRTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ahmednfwela]

@redsk
well there has been a hot debate (authts/oidc-client-ts#152) over this, and some people think sharing client_secret is still safer than implicit flow, but I disagree with both.

the actual "best" practice, would be using your own IdP server that supports PKCE which you login with, and support google auth server side instead of client side.

EDIT: I also state this in the docs: https://bdaya-dev.github.io/oidc/oidc-usage/#loginimplicitflow

[redsk]

@ahmednfwela yeah both solutions are actually bad and the real solution is what you described.

Apparently there's a plugin for spring boot which is what I use as backend.

Hopefully it's not too messy to deal with the redirects... :)

[ahmednfwela]

@redsk Do you still need more clarification in the docs or can this issue be closed ?

[ahmednfwela]

Closing this for inactivity

[ghost]

@redsk no it isn't a security risk since google doesn't consider the client_secret really a "secret" for web, you can think of it as part of the client_id.

another alternative is to use implicit auth.

Not sure what google recommends, but if i am using your library for Microsoft Entra login, i wont be comfortable storing clientSecret in the code.

[ahmednfwela]

@redsk no it isn't a security risk since google doesn't consider the client_secret really a "secret" for web, you can think of it as part of the client_id.

another alternative is to use implicit auth.

Not sure what google recommends, but if i am using your library for Microsoft Entra login, i wont be comfortable storing clientSecret in the code.

since entra supports auth code with PKCE it would be better to use that instead