Where Are Microsoft Graph Access Tokens Used? — Organizing the Flow Up to API Calls with Diagrams

About This Article
This article is organized based on official Microsoft Graph / Microsoft identity platform documentation as of 2026-09-06.

Verification Status: 📘 Official Specifications Verified / No Real Tokens Used
Access tokens are treated as sensitive information, and real values are never included in articles or logs.

When sending an API request to Microsoft Graph, the access token is used as authentication material for Graph to determine whether the call originates from an authorized app and user. The app acquires a token from the Microsoft identity platform and typically sends it to Graph as a Bearer token attached to the HTTP Authorization header.

From Token Acquisition to Graph Calling

sequenceDiagram
    participant U as User / App
    participant I as Microsoft identity platform
    participant G as Microsoft Graph

    U->>I: 認証・token要求
    I-->>U: access token
    U->>G: Authorization: Bearer <token>
    G->>G: tokenとpermissionを検証
    G-->>U: 許可されたAPI結果

The architecture is not designed to send the username and password directly to Graph with every request.

What Is a Bearer Token?

A Bearer token is a credential with the property that “anyone possessing the token” can use it. Therefore, treat real values with the same level of care as passwords.

Conceptually, the HTTP request looks like this:

GET /v1.0/me HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer <access-token>

Be careful not to paste actual tokens into articles, GitHub, screenshots, or AI chats.

Delegated Access and App-Only Access

There are broadly two access scenarios in Microsoft Graph.

flowchart TB
    A[Graph APIを呼ぶ] --> B{誰として動く?}
    B -->|サインインユーザーの代理| C[Delegated access]
    B -->|アプリ自身| D[App-only access]
    C --> E[Delegated permissions / scopes]
    D --> F[Application permissions / app roles]

Delegated access

A user signs in, and the app calls Graph on behalf of that user.

In this case, not only the delegated permissions granted to the app, but also the permissions the user themselves has on the target resource are factored in.

App-only access

Graph is called using the app’s own identity without a signed-in user.

This is sometimes used for background processing, daemons, or services. Because application permissions tend to have a wide scope of impact, administrator consent and the principle of least privilege design are important.

Permissions Are Not “All-Access Passes” to APIs

Microsoft Graph exposes granular permissions for each resource and operation.

For example, there are permission names like User.Read, which are chosen based on the required operations.

Official Microsoft guidance also recommends requesting the minimum permissions required by your application.

flowchart LR
    A[やりたいAPI操作] --> B[必要permissionを確認]
    B --> C[最小権限を選ぶ]
    C --> D[必要なconsent]
    D --> E[token取得]
    E --> F[Graph呼び出し]

Rather than proceeding with an approach of “it didn’t work, so let’s add broader permissions,” check the official permission table for the endpoint.

Understanding Why /me Cannot Be Used with App-Only

/me is an alias representing the “signed-in user.”

It has meaning in delegated access because there is a signed-in user. On the other hand, in app-only access, there is no user signed in, so the context of /me does not exist.

Understanding this distinction helps isolate issues such as why something worked in Graph Explorer but fails in a custom daemon.

Do Not Over-Trust Access Tokens in Your Own App

Access tokens may contain claims, but the client side should not determine that a token is valid simply because it was able to decode the contents.

Resource servers like Graph validate the token and determine whether to authorize the target API call.

You need to distinguish this responsibility from articles discussing decoding JWT formats for learning purposes.

How to Think About 401 and 403 Errors

To simplify:

• 401 series: Suspect authentication materials such as a missing, invalid, or expired token.

• 403 series: Suspect that even though the token is recognized, there might be insufficient permissions or resource rights required for that operation.

However, for actual errors, always check the Graph error body and the official documentation for the relevant endpoint.

flowchart TB
    A[Graph request failed] --> B{HTTP status}
    B -->|401| C[token取得・送信・期限などを確認]
    B -->|403| D[permission / consent / user権限 / RBAC等を確認]
    B -->|その他| E[Graph error bodyと公式docsを確認]

Summary

• Access tokens are credentials used to have Graph determine whether a call is authorized.

• They are normally sent via the Authorization: Bearer header.

• Delegated access acts on behalf of a user, while app-only acts as the app itself.

• Keep permissions to the strict minimum necessary.

• /me is used within the context of delegated access.

• Do not leave actual tokens in logs, GitHub, articles, or AI tools.

Official and Primary Sources

Microsoft Learn — Authentication and authorization basics
https://learn.microsoft.com/en-us/graph/auth/auth-concepts

Microsoft Learn — Overview of Microsoft Graph permissions
https://learn.microsoft.com/en-us/graph/permissions-overview

Microsoft Learn — Get access on behalf of a user
https://learn.microsoft.com/en-us/graph/auth-v2-user

RFC 6750 — Bearer Token Usage
https://www.rfc-editor.org/rfc/rfc6750.html