Is Oauth2.0 appropriate for first-party apps?

Question

I am developing a SPA application in angular and I have a lot of confusion about the correct way to implement authentication and authorization.

First of all, the application is a first-party app, which means that I am developing both the authorization server and resource servers.

The users that logs in the application must have full access to their resources on the platform.

So, I am doing it using OAuth2.0 and I have a couple of doubts about the domain of the protocol as well as security concerns.

First question:

The first question is if OAuth should be actually used to authorize first party applications. From my understanding this is a delegation protocol used to grant a third-party application controlled access to the user's resources on the platform, upon user consent. How does this fit in the context of a first-party app? In that case the app should get an access token with a scope that allows full access, right?

Second question:

Since this is a Single Page Application I couldn't store a secret on client side. So I am opting for using the authorization code grant with PKCE which would seem to be appropriate to manage this scenario. In this case I wouldn't ask for a refresh token but I would only retrieve the access token and using silent check to refresh it. I do not want to have refresh token insecurely stored on the browser. Is this PKCE really secure? The secret is generated dynamically but a attacker could eventually create a system using the same public client id and managing the PKCE properly, and finally get an access token that, in my case, gives full access to the users resources.

I could in the future allow controlled access to my app's resources to third party app, that's also one of the reason why I stick with OAuth.

Fortenberry

Answer 1

The first question is if OAuth should be actually used to authorize first party applications. From my understanding this is a delegation protocol used to grant a third-party application controlled access to the user's resources on the platform, upon user consent. How does this fit in the context of a first-party app? In that case the app should get an access token with a scope that allows full access, right?

Yes, this makes sense to me. We skip the 'grant permissions' step for our own apps.

Is this PKCE really secure?

Yes, even without PKCE, authorization_code is pretty secure. Adding PKCE solves a a few potential security issues, but I would be somewhat inclined to call them edge cases. It is definitely right now the recommended choice.

The PKCE rfc has more information about the motivations behind PKCE:

https://www.rfc-editor.org/rfc/rfc7636#section-1

Singlet

Thank you for the answer. I decided not to opt for auth for several reasons. In my application I use the usual sessions for login and access token to access the resources on the microservices. The access token is a signed token, I think OAuth doesnt really fit to my architecture at the moment – Fortenberry

@Fortenberry Did you implemented your own solution? I was trying to implement also Oauth2 but at the end I decided to implement my own authorization server and authentication server. Kind of password grant oauth2 flow – Ventriloquist

@Ventriloquist yes I implemented my own solution. Because I do not need to provide third party access to my application at the moment neither I want to deal with refresh tokens in my SPA. I just implemented authentication with session + JWT – Fortenberry

Answer 2

I actually came here looking for the answer to Question 1. My take is that in situations where we have no third party apps requiring access to our APIs we do not need OAuth. If we still need to use OAuth, then we can use Resource Owner Password Flow for first party apps. I have not seen any convincing answer anywhere confirming or rejecting this opinion but this is purely based on my understanding of OAuth.

Now, I am mainly writing this to answer Question 2. PKCE protocol is secure and attacker would not get token in this scenario. The reason is that the Authorization Server uses pre-registered "Redirect Uri" to send the token to. To be precise, the Auth Server would simply ask the browser to redirect user to "Redirect Uri appended with Access Token". Browsers do not allow javascript interception of Redirection requests. Therefore, an attacker would not be able to get hold of the token and the user will be redirected from attacker's site to yours at the end.

Kylix