How to set up an Entra ID application registration for calling Microsoft Graph

Last updated on November 2, 2024

Whenever you want to call Microsoft Graph from your custom solutions, you need to have an application registration in your Azure Active Directory first. The application registration is required for obtaining the access token you need for using Graph operations.

Creating an application registration is a simple and quick thing to do, as long as you know what you are doing. In this blog post, I’m going to show you three — or four depending on how you want to count it — ways to create an application registration in the Azure AD and teach you how you can choose the right way depending on your situation.

Table of Contents

• How to choose the right way to authenticate
• I want to authenticate to Graph with …
  • The application identity
  • The logged in user
  • Service credentials
• Creating the application registration
  • Setting the permissions
  • Creating the client secret
• Information required for authentication
• Afterword

How to choose the right way to authenticate

When you are creating your application registration, you are asked to select its type. Which type you should choose depends on what type of permissions (application or delegated) you want to call Graph with, how you are planning to authenticate and from what kind of an application.

The first thing to do is to check the Graph documentation for what kind of permissions are required by the operations you are planning to use. For every operation, there is a page in the documentation with Permissions section, which tells you what kind of permissions are required for using the operation. Ideally, both delegated and application permissions are supported, but quite often only delegated permissions are available.

Delegated permissions mean that you need to authenticate using a user account. While using delegated permissions, you execute the Graph operations as the user, and the operations can only be executed for the resources the user has been given access to. Application permissions, on the other hand, mean that you need to authenticate using the application’s credentials, and you execute Graph operations using the application’s identity. Unlike a user account, an application isn’t given permissions to any resources. The application can access all resources by default.

To use application permissions, you need to get authorized using the OAuth 2.0 client credentials flow. This can be achieved in two ways: using a client secret or a certificate. In this blog post, I’ll show you how you can authenticate using a client secret. A client secret is much easier and faster to set up and use than a certificate, and for calling Graph it is completely sufficient. However, if you also want to call the SharePoint Online REST API, then you need to set up a certificate. So, if you need to use both SharePoint Online and Graph API in your application, you might as well use the certificate for authenticating to Graph as well.

If you are going to use delegated permissions and your app has user interaction, then it’d be a good idea to execute the operations using the logged in user’s identity. In the case your app has a backend, use the authorization code flow, and if you are calling Microsoft Graph from JavaScript, use the implicit grant flow.

If some operation requires delegated permissions and you need to call it from, e.g., Azure function or Microsoft Power Automate, you can authenticate using a set of service credentials (a user account created for the purpose). This is referred to as the resource owner credentials flow or the password grant flow or the resource owner credentials password grant flow (“a dear child has many names”). Essentially this is similar to authenticating with client credentials, except this time you are using delegated permissions instead of application permissions. Note that the service account needs to be given access to the resources you want it to be able to use via Graph. You can use either Native or Web app / API type of app registration. If you use the web app / API, you also need to create a client secret and use it when authenticating. For a native app registration, username and password are enough.

I want to authenticate to Graph with …

The application identity

When you want to authenticate using the client credentials, follow the steps below with these options:

• Create Web app type of app registration
• Select the permissions from the Application permissions section

The logged in user

When you want to call Graph as the logged in user, follow the steps below with these options:

• Create Web type of app registration
• Select the permissions from the Delegated permissions section

Also, if you are using the implicit grant flow (you are authenticating from JavaScript), you don’t need to create a client secret. Instead, you need to click on the Manifest button (next to the Settings button) and change oauth2AllowImplicitFlow value to true.

Service credentials

When you want to authenticate using service credentials, follow the steps below with these options:

• Create either Web or Public client/native (mobile & desktop) type of app registration
• Select the permissions from the Delegated permissions section

If you choose to create a native type of app registration, you don’t need to create and use a client secret. When using web type, you still need one.

Creating the application registration

1. Go to Azure portal and log in.
2. Click on Azure Active Directory on the left-hand side navigation.
3. Navigate to App registrations
4. Click on New registration at the top
5. Give your application registration a Name that describes your app or purpose
6. Select the supported account types. If you are planning on offering the application only for the users in your organization’s Azure AD (including invited guests) use the default option. If you are creating a multitenant application, look into the other options and choose the one that fits the best for your scenario.
7. In the Redirect URI (optional) drop-down, select [the type mentioned above]
8. Type the redirect URL to the field. This should be the URL of the page where the user is directed to after signing in, such as the home page URL. If your app doesn’t have a home page, you can type anything here, as long as it is a valid URL (e.g. https://anything), or leave the field blank. The URL is automatically added to the Reply URLs of the app registration. Reply URLs are the locations where the user is allowed to get redirected to after authentication (a security measure).

Setting the permissions

Now your application registration has been created, but it won’t be of much use before we configure the permissions for Graph API. To do that follow these steps:

1. Click on API permissions on the left
2. Click Add a permission
3. Select Microsoft Graph
4. Then choose whether you want to grant delegated or application permissions. Which one you should choose depends on your chosen authentication method. Check the [section mentioned above].
5. In the Select permissions section, tick the checkboxes for the permissions mentioned in the Graph documentation of the operation you want to use. Use the principle of least privilege (grant only the absolutely required permissions, no more). In the Graph documentation, the permission of least privilege which still grants the required permissions is mentioned first.
   
6. Finalize the permission settings by clicking Add permissions and then Grant admin concent (if you selected permissions that require admin consent). Note that if you are not an admin, you won’t be able to complete the last step yourself, but need to ask your admin friend to click on the button for you.

Creating the client secret

The last thing we need to set up is the client secret.

1. On the left, click on Certificates & secrets
2. Click on New client secret
3. Fill in the Description. It can be anything you like but I recommend you mention the application/service where the secret is going to be used.
4. Select Never from the Expiration section. Nothing is more annoying than when your app stops working because your client secret has expired.
5. Press Add and copy the Value to a safe place (preferably Azure Key Vault). It is a password, so handle it with care. Copying the key value now is important because after you close the view, you won’t be able to see the key value again. If you lose the secret, you have to create a new one.

Information required for authentication

Now our application registration is ready for use and we are able to get authorized to use Graph. For that, you need to note down some information from your Azure AD:

• Directory (tenant) ID. This can be seen on the Overview blade.
• Application (client) ID. This can be seen on the Overview blade.
• And finally, you need the client secret. You should have already copied it somewhere earlier right after you created it, but if you didn’t, create a new one.

If you are using the authorization code flow, you also need the code query string parameter value you get in the URL when the user is returned to your app after logging in. And if you are using the resource owner credentials flow, you naturally need the username and password of the service account. You should also store the service account password in Azure Key Vault.

Afterword

Thank you for reading this article; I hope it was useful to you! I mostly wanted to write these instructions, so I can refer to them from my other blog posts. There are plenty of instructions online for setting up application registrations, but I couldn’t find one article that I would have liked so much that I would have wanted to link to it from my blog. This way I can also have more control over the instructions I’m giving to you, my dear reader.

Please, do take a look at my other articles if you are visiting my blog for the first time. And if you want to get notified when I publish new content, the best way to do that is to follow me on Twitter. I also tweet about other thing going on in the Microsoft ecosystem, including good articles I’ve read, and small tips and tricks I come across while working on my projects.

Thank you again for reading, it means a lot to me, and until next time!

Laura