3

A simple question which I cannot find any guidance on the RFC6749 (or related) spec.

I have an eCommerce public client (SPA & mobile), where I want to postpone as much as possible the authentication process (possibly registration too for new customers). I will only ask the customer at the end of his purchase journey to authenticate and place the order. Meanwhile, before the authentication, this public client needs to call back-end REST APIs which are OAuth2 protected.

So how can I perform correct and secure calls to the APIs?

  • system to system calls -> Client credentials grant type -> NO, because of the public client (only confidential clients are allowed in this type)
  • public client BCP-> Authorization code grant type with PKCE? -> NO, because no end-user authentication/consent

Does somebody have a similar case? Can you see a pattern to make this secure enough within the OAuth2 framework?

1
  • 1
    If you are allowing even a new customer (who hasn't even registered) to go through all those endpoints, then why are you doing any kind of auth check at all?
    – Limit
    Feb 22, 2021 at 2:37

2 Answers 2

1

You haven't provided enough information to say for sure, but the default response to your question is "you just can't do that". OAuth isn't magic; the authentication has to come from somewhere. If you don't authenticate your client and you don't authenticate your user, you can't enforce authorization checks because you have no idea who anybody is!

With that said, the obvious first question is "why are the REST API calls behind an authorization boundary? Do they need to be?" Authorization - like any security measure - isn't something you do "just because"; every security measure should exist because it mitigates an attack. If your APIs are designed to be called by arbitrary, anonymous users - perhaps they use transparent anonymous sessions to distinguish shoppers but don't require any authentication until the end of the purchase process - then there's no reason to put them behind OAuth; just issue a unique anonymous token and use that instead.

0

I think you should refere to the current draft of OAuth for Browser-Based Apps:

9.3. Client Impersonation
As stated in Section 10.2 of OAuth 2.0 [RFC6749], the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured.

In my understanding, it is currently not recommended to not show a consent page, what is your plan, if I understood your question right, since the consent page is what protects public clients against client impersonation. This applies indepentent of the used grant type or the extension (e.g PKCE) you use.


If you would have previously processed an authorization request of a specific client (your description reads like you did not) and you use fixed redirect URIs, you could use the redirect URI to identify the client:

If authorization servers restrict redirect URIs to a fixed set of absolute HTTPS URIs, preventing the use of wildcard domains, wildcard paths, or wildcard query string components, this exact match of registered absolute HTTPS URIs MAY be accepted by authorization servers as proof of identity of the client for the purpose of deciding whether to automatically process an authorization request when a previous request for the client_id has already been approved.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .