13

I am finding Application Registrations in Azure very confusing. In my question here AuthClientId and Application Id turned out to be the same thing, so why are two names being used?

What is the logic behind this choice of naming?

[Update]

From Joy's link to the glossary I see

application id (client id)

"The unique identifier Azure AD issues to an application registration that identifies a specific application and the associated configurations. This application id (client id) is used when performing authentication requests and is provided to the authentication libraries in development time."

I see that Client Id links to a page at ietf.org Which states

"2.2. Client Identifier

The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client."

I guess the metaphor is all about the supplier,customer,product relationship Where the supplier is Active Directory, the product is authentication and the customer is an application registration.

It is the concept of an "application registration" as a customer that I am having trouble getting used to. I seek help understanding the choice of words.

The idea of a multi-tenant application does not really work with the "client" metaphor.

[Update] This link is the most helpful yet and the most authoritative Copying from the link

1.1. Roles

OAuth defines four roles:

resource owner An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

resource server The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

client An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.

However it is still confusing.

"An application making protected resource requests on behalf of the resource owner and with its authorization "

What does it mean by "making a protected resource request on behalf of the resource owner"?

[Update]

After studying Wayne Yang's answer I found this picture at Slack's oauth page OAuth 2.0 authorization code grant flow

Community
  • 1
  • 1
Kirsten
  • 15,730
  • 41
  • 179
  • 318
  • 1
    A web application is a confidential client running on a webserver. You could refer to the [link](https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary#application-id-client-id) and [client id](https://tools.ietf.org/html/rfc6749#page-15). – Joy Wang Jun 28 '18 at 07:28
  • Thanks @JoyWang I updated the question. – Kirsten Jun 28 '18 at 23:10
  • Checking this out https://dev.to/rmorschel/oauth-for-dummies – Kirsten Jul 03 '18 at 05:45

2 Answers2

8

why is an AuthClientId also called an Application Id?

Client Id is the standard definition in OAuth2.0 protocol. It's actual application too. Application Id is just another name in Azure Portal.

This name is more nearly to the application meaning itself. E.g Native Client can be called with the client, but a Web App/Api is actually a server service which runs in a server. But they are all applications.

So Application id is better to make sense for common users. But client Id is a standard definition which you cannot change it.

What does it mean by "making a protected resource request on behalf of the resource owner"?

It means that the client can on behalf of users to request an access token and send the access token to the Resource. (If you let users do this by themselves, it's unsafe and complex)

In OAuth2.0 framework, the client is the bridge for Users(Resource Owner), the App (protected resource) and the Identity provider(Authorization server). If a user wants to access to the SaaS app, he will send an authorization request to the client, not the Authorization Server directly. Then the client can on behalf of the user to request an access token from the Authorization server and send access token to the App.

Here is the protocol flow:

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

From C to F, Client is on behalf of the resource owner to obtain an access token and send access token.

For AAD, there is a document for Authorize access to Azure Active Directory web applications using the OAuth 2.0 code grant flow:

enter image description here

Client: Native App

Resource: Web API

Resource Owner: the User

Authorization Server: AAD

Here the Native app is the client which on behalf of the user to request token and send the token to the resource.

Community
  • 1
  • 1
Wayne Yang
  • 9,016
  • 2
  • 20
  • 40
  • Thank you, but I am having a hard time understanding that all the users are the resource owner. – Kirsten Jul 03 '18 at 04:03
  • Hi @KirstenGreed . Not All users are the resource owner. If you want to restrict user assignment, you can go to AAD> Enterprise application > Select your app > User assignment required> Set to Yes> Add Users in Users and groups under this application. – Wayne Yang Jul 03 '18 at 04:54
  • A user as a resource owner is also counter intuitive.... but I guess that is a different question. – Kirsten Jul 03 '18 at 05:42
  • Oh wait, looking at https://dev.to/rmorschel/oauth-for-dummies are the facebook accounts etc the resource? – Kirsten Jul 03 '18 at 05:48
  • Hi @KirstenGreed , Not really. Facebook and Google+ accounts are just Identity provider credentials. The resource should be some App or API resources. – Wayne Yang Jul 03 '18 at 06:03
  • @KirstenGreed , Also, strictly speaking, resource owner is the owner of the app. If you want to use Resource owner password credentials flow, you can add the user to the owner of the application in the application registration/enterprise application in AAD. But widely speaking, users who can access the app are all resource owners if there are not other roles for this app. – Wayne Yang Jul 03 '18 at 06:15
  • I asked about it at https://stackoverflow.com/questions/51148139/in-oauth2-where-are-the-resources-that-the-resource-owner-owns – Kirsten Jul 03 '18 at 06:49
  • Are you going to update the information about the resources ? – Kirsten Jul 06 '18 at 03:13
  • Hi @KirstenGreed . This question is different from the OpenID connect one. I think this answer can give a correct response for your question. – Wayne Yang Jul 06 '18 at 05:30
  • I am finding "(If you let users do this by themselves, it's unsafe and complex)" confusing because the the users do indeed have safe access to the resource. ( ie Facebook user can access their Facebook Assets) – Kirsten Jul 06 '18 at 07:18
  • 1
    @KirstenGreed . That's OpenID connect, NOT Oauth2.0. OAuth2.0 cannot do that. Also, actually, even in OpenID connect, there is also client in the identity provider. OpenID is based on OAuth. For end user, you cannot feel How the backend works. If you use Fiddler to catch the traffic you will find that there should also be a clientid in the http request. Use cannot obtain token and send token direclty. – Wayne Yang Jul 06 '18 at 07:54
  • 1
    Also, this is what and why OAuth2.0 can do. – Wayne Yang Jul 06 '18 at 08:35
4

In Azure, to create a Service Principal you have to register an Application. Thats why its called Application Id (AppId). So:

AppId = ClientId = AuthClientId = Id of your Application

and

TenantId = DirectoryId = Name or Guid of your Azure Active Directory

Martin Brandl
  • 56,134
  • 13
  • 133
  • 172
  • What is a client? – Kirsten Jun 28 '18 at 06:22
  • 1
    I don't understand your question. A client is a software (or hardware) that access a remote service. – Martin Brandl Jun 28 '18 at 06:29
  • so it does not make sense for a client to also be called an application but that is what your answer implies. I updated the question to show that I am trying to understand the thinking behind these name choices. – Kirsten Jun 28 '18 at 06:32
  • 1
    Hi @KirstenGreed , Client Id is the standard definition in [OAuth2.0 protocol](https://tools.ietf.org/html/rfc6749#section-1.1).It's actually application too. Application Id is just another name in Azure Portal. This name is more nearly to the application meaning itself. E.g Native Client can be called with the client, but a web app/api is actually a server service which runs in a server. But they are all applications. So Application id is better to make sense for common users. But client Id is a standard definition which you cannot change it. – Wayne Yang Jul 02 '18 at 07:03
  • Thank you @WayneYang-MSFT , the link you give has the answer. I updated the question to show that even with the link I still find the answer confusing – Kirsten Jul 02 '18 at 22:09