3
votes

My Scenario

I have the following pieces/parts of software:

  • dedicated server with a Windows Service that exposes REST API with OAuth 2.0 authorization.
  • Type 1 clients: Services on different servers that use REST API. Only organization administrators have access to these servers.
  • Type 2 clients: Desktop application which make calls to the REST API.

According to RFC 6749 type 1 clients are confidential, type 2 clients - public.

Decision has been made to use resource owner password credentials authorization grant for both types of clients for the first release. For type 1 clients it seems to be OK as they are capable of maintaining the confidentiality of their credentials and cannot use authorization code grant (there are no interactive user).

Auth Details

  • Authorization endpoint returns both access and refresh tokens to both type 1 and type 2 clients.
  • All clients (type 1 and type 2) can use refresh token to obtain new access and refresh token.

Question/Dilemma/Issue

Public clients do not have secret. It means that if anyone gets hold of the refresh token and client ID (last one is not secure), then he may use it to get new access token and use REST API.

  1. Is it OK to generate refresh token for type 2 clients (public) from security standpoint? Or I must not return refresh token along with access token for type 2 clients if resource owner password credentials authorization grant is used.
  2. Type 2 clients, are they really public? Can I treat desktop clients as confidential and generate secret for them? Desktop app will read client secret from a configuration file (it will be encrypted using AES 256), that is distributed by the administrator to user machines inside organization network?
1
Under the section native application in the RFC, it clearly states that client credentials can be extracted from the application. It can be done via either extracting the application itself or logging the network activity.AnkitNeo

1 Answers

1
votes

I know this is late, but yes, you can issue Refresh Tokens to public clients.

Section 10.4 of the RFC says this:

Authorization servers MAY issue refresh tokens to web application

clients and native application clients.

There are a number of security implications so you should read that carefully, but there is no outright prohibition in the spec on doing that.