Client secret is revealed

[valstu]

I found out link to this repository from the official Ubisecure SPA documentation https://www.ubisecure.com/developers/single-page-applications/

I went through the examples briefly and noticed that on spa.html file, line 87 the invokeTokenRequest function is using the client_id and client_secret.

SimpleSPA/docs/spa.html

Line 87 in 2decdb8

function invokeTokenRequest(configuration, client_id, client_secret, code) {

This basically means that any user will have access to client_secret key. Isn't this a security risk?

Of course it could be that the provider is configured in a way that this doesn't cause any actual risks.

[psteniusubi]

Hi, Yes I’m aware client secret is there and I agree it would be better if it was not there, as would be the case when working with a public client. However the OIDC provider I’m using does not support public clients without client secret. To mitigate risks I have configured the client in the same way a public client would be set up. So there should not be any more security risks than with a public client. This exact issue is mentioned in the best practices document for browser-based apps https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-03#section-9.2 Thanks, Petteri Stenius From: Valtteri Karesto <notifications@github.com> Sent: keskiviikko 11. syyskuuta 2019 14.44 To: psteniusubi/SimpleSPA <SimpleSPA@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [psteniusubi/SimpleSPA] Client secret is revealed (#1) I found out link to this repository from the official Ubisecure SPA documentation https://www.ubisecure.com/developers/single-page-applications/ I went through the examples briefly and noticed that on spa.html file, line 87 the invokeTokenRequest function is using the client_id and client_secret. https://github.com/psteniusubi/SimpleSPA/blob/2decdb8bfcffd3e9a8165c975d4ee5fac3eff213/docs/spa.html#L87 This basically means that any user will have access to client_secret key. Isn't this a security risk? Of course it could be that the provider is configured in a way that this doesn't cause any actual risks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1?email_source=notifications&email_token=AEISFZ5C2EJJ5UFD7RTD4JDQJDKWPA5CNFSM4IVS4ZCKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HKWE6YQ>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEISFZ7M45BGDGKZIH4RF6TQJDKWPANCNFSM4IVS4ZCA>.