Is oidc/oauth2 protocol safe from malicious native apps when redirecturl starts with https://?

Question

Let's say I have an oidc idp set up where a js browser client has registered an app with redirecturl of https://sub.domain.com/callback that retrieves access tokens.

Q: Are there any potential security issues from users unintentionally installing malicious apps on their native devices that somehow can pretend to be a browser and hijack information from the callbackurl with an in-app browser or similar?

If so, are there any specific security measures that can counter this server side or by protocol implementation?

I feel I'm lacking a bit in my knowledge about native devices and what native apps can actually do that may arise security issues in oidc.

(This is not a question about how security in native apps can be improved with pkce or other measures but rather if malicious apps can attack the implicit flow thats supposed to be used in a user web browser).

Answer 1

Implicit flow is flexible but as you have figured out there are concerns. Protocol itself mention about this,

1.3.2 Implicit

Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available.

4.2. Implicit Grant

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

10.6 Access token impersonation

For public clients using implicit flows, this specification does not provide any method for the client to determine what client an access token was issued to.

Also, PKCE is not for implicit flow.! It is a mechanism to protect public clients which use authorization code flow.

What you can do ?

Proper selection of flow

As you have figured out, PKCE provide additional protection for public clients who use authorization code flow (Hybrid flow of OpenID Connect can use PKCE). So if your client is public, it is advisable to use PKCE.

Using TLS

OAuth2.0 specification mention and recommend the usage of TLS

10.9. Ensuring Endpoint Authenticity

In order to prevent man-in-the-middle attacks, the authorization server MUST require the use of TLS with server authentication as defined by [RFC2818] for any request sent to the authorization and token endpoints. The client MUST validate the authorization server's TLS certificate as defined by [RFC6125] and in accordance with its requirements for server identity authentication.

TLS will ensure end to end protection by encrypting response. So if you are using Implicit flow, it is advisable to use TLS. (A good article on URLs over HTTPS cab be found through this link)