API Auth

[josh-gaby]

I've been puting together a Chrome/Firefox extension to make desktop access easier/faster (https://github.com/josh-gaby/2fauth-browser-extension).
I currently have it setup to encrypt and store the personal access token using a locally set password which works okay, but it would be a lot nicer if you were able to use your 2fauth password to for access rather than one specific to the extension.

With the current process of generating a token on the hosted app and sending it with all requests from the extension, I can't think of any simple mechanism that would allow the users password to be confirmed.
My first thought was a new auth endpoint to confirm a users password but because the token is encrypted by the extension while it's locked, it cant be used to authorize the api call that would be required to validate the unlock request.

Any thoughts on a simple mechanism that could be implemented in the API that would allow for this or is a seperate password for the extensions not an issue worth worrying about?

[Bubka]

Hi Josh,
I just came back from holiday so this is a quick reply, I still have a lot to do. Thanks for your involvement, I can't wait to find out your extension.

What you want to implement seams to be the behavior of the Bitwarden extension: On browser opening the user unlock the extension with a pwd, then the extension remains unlock during the session and is locked on demand or on session ending. Is that right?

[josh-gaby]

That's the general idea and what I have begun to implement, except with a password that must be set in the extension due to the current API implementation not providing any authentication endpoints.

If the API provided an Auth endpoint that could take the users email and password and return an Auth token and a refresh, then instead of the user having to generate an access token and the extension having to protect that using client side encryption (never an ideal situation), they could login using the same email/password combination they have set for their 2FAuth account.

[Bubka]

I think Authorization Code grant of OAuth2 is what you expect: https://oauth2.thephpleague.com/authorization-server/auth-code-grant/ (according to the decision tree available here https://oauth2.thephpleague.com/authorization-server/which-grant/)

2FAuth uses the Laravel Passport package so enabling this OAuth flow is quite easy, I will work on it.

[josh-gaby]

I don't think the authorization code grant would be suitable for a browser extension for two reasons:

1. I would need to send the user to their 2FAuth instance each time they needed to unlock the extension which I don't think would make for a very good user experience.
2. It requires a redirect URI to send the user back to once they have successfully logged into their account, I'm not sure if that is even possible to do with a browser extension.

The OAuth workflow I was thinking of implementing is the Password Grant, this would be ideal because then I can store the username inside the extension and just have the user enter their 2FAuth password directly into the extension to unlock it.

[Bubka]

You're right, I read the OAuth doc too fast and without a ☕💀

[josh-gaby]

I've just checked and the Password Grant is already available via oauth/token thanks to the php artisan passport:install command, so all that needs to be done to enable this is would be to add some UI to enable creating/edting/deleting clients.

[josh-gaby]

Also, the default expiry for the access token generated seems to be roughly 1 year, that is probably to long and could be reduced to an hour or so.

[Bubka]

Running php artisan passport:install automatically creates a Password Grant Client (PGC). This type of client is the one the Laravel/Passport documentation suggests to use for the PG flow: https://laravel.com/docs/9.x/passport#password-grant-tokens. So there is no need to run it again with php artisan passport:client --password.

But there is a drawback with the PG flow using a PGC, the client_secret (beside the client_id) needs to be passed by the consuming app (here the browser extension) when it requests a token by POSTing to /oauth/token. So we are back to your initial thought, it's not a good practice to have a secret stored in a public client.

In the very last post of this discussion laravel/passport#984 we can see that using a Public Client should also work in a PG flow. It's a client sets with secret=NULL, the one normally used in the Code Grant with PKCE flow. But how is it secure to use it in a PG flow?

Regarding the token expiry, I'm going to add an env var to customize it.

[josh-gaby]

I wasn't saying it needs to be run again, I was just pointing out that the password grant was already available because that command is run during the install process.
It was just a simple way of generating a client ID and secret for testing purposes.

In regards to the client type, because an extensions source is always available to view, nothing can be done to add any extra security so using no secret is just as secure as using one.
My reasoning for wanting to use the PG flow is so that the end user can use their 2FAuth password to login. It also allows me to delete the access token from the browser entirely when the extension locks rather than having to encrypt and store it client side which feels a lot more secure.

Compared to the current API auth method of generating a permanent access token, even using no secret, having the token change each time you login would surely be more secure?

[Bubka]

We agree, having a login+pwd is the best solution. I'm just sharing my thoughts and finds because I want to know more precisely what needs to be implemented and how this will be consumed by the extension. This also gives me the opportunity to learn more about OAuth flows, especially the differences between them and the security concerns they address.

I think I'm going to implement all stuff to enable every OAuth flows, which will takes me some time. But I also don't want you to be stuck in your dev. Thus the question is: Given that you have a way to generate some clients using php artisan and the oauth/token endpoint is available to get an access token, do you need some quick addition? (except the env var to customize the token expiry)

[josh-gaby]

My thinking on the password flow is that having a client ID and no secret will leave the users account to be protected by their username/password which is the same protection they currently have when using the standard login.

To answer your question, if you are going to eventually provide a mechanism for a user to create their own client ID/secret then there is nothing extra needed for my development to continue.
I can add extra instructions on my repo to let people know how to get a client ID/secret until your implementation is done.

[Bubka]

npm run build:chrome fails for https://github.com/josh-gaby/2fauth-browser-extension/tree/feature/password-grant-workflow on my side (at commit 2943dec) . You too?

[josh-gaby]

It built fine for me last time I ran it, what error are you getting?

Looks like I missed a few new files in my last commit after I implement a new loading spinner, if you do a pull (to c7b7dda) and rebuild, it should be working.

[Bubka]

It works now 👍🏻

[josh-gaby]

I have moved the extension out of alpha and published it to the Chrome Extension store and Mozilla Add-On store under the name 2FAuth so its easy to find.

For now it's using the OAuth token method for access.