Many questions on Part 4 and OAuth

[JeanLucEsser]

First I have to say that your series is one of the best out there, especially Part 4 about Laravel Passport and Authentication. But I feel a bit like after a Lost episode, I had a billion questions, and now I have a billion more ;)

So let's dive in:

1/ What are the security implications of leaking a client id and/or secret? I mean I get the idea of added security, it never hurts, but I have a difficult time understanding the real danger of the client secret being hacked. After all it is the Password Grant, not the Client Credentials one. Plus, according to the specs, Password Grant should be used only with first party clients (trusted). So is the added security of using a proxy worth the overhead?

2/ We should use a client id/secret per client (or application). But in your example the proxy is responsible for not only the client secret but for the client id as well. Shouldn't the client id be passed along the user/pass? Or should we use another code to identify the client for which the proxy will get the id/secret?

3/ If you cannot trust your javascript application to keep a secret, you shouldn't trust it to keep the refresh token. And if I get what you are doing, you only exchange cookies between the client and the proxy to handle the Refresh Grant. Alex Bilbie seems to go one step further in implementing that strategy for the access token as well (see https://github.com/thinkingmik/api-proxy-laravel or https://alexbilbie.com/2013/09/securely-store-access-tokens-in-single-page-web-app/). It uses the proxy and cookies for every api call. Do you think this is going one step too far? Does using a short lived access token mitigates for this?

4/ Is it good practice to set the refresh token to never expire (that's what you do by setting its expiration to now + 10 days as the token is sent back every time it is refreshed). Shouldn't we use an end of the week strategy for example, a fixed date?

5/ Do you think using this proxy strategy resolves the issue of managing a cross-domain SSO? If all we exchange are encrypted cookies and they are managed by a thin proxy layer, then this could potentially solve cross domain single sign on.

I'll stop here, I have many more, but outside the scope of your article. I may ask those to Alex Bilbie first, see what he has to say about it.

Again, thank you for reading, and thank you for your excellent four part series.