Registering an App – Developer Guide | Help Center

The first step in connecting your app to Manabu2 is to register it and get a client ID. This guide walks through each field on the registration form, including the ones you can't change later.

You need the developer or organization administrator role to do this.

How to register an app

Open My Page and, on the card for your organization, click Applications.
Click Register app (アプリを登録) in the top right.
Fill in the form and save it.

The form fields

App name

Shown on the form as App name (アプリ名). This is the name users see. For a third-party app, the consent screen at sign-in says "(app name) is asking to use your Manabu2 account." Pick a name that tells users at a glance which app it is.

Client ID

Shown on the form as Client ID (クライアント ID). A public string that identifies your app: 3–64 characters, using lowercase letters, numbers and hyphens.

You can't change the client ID later. It ends up embedded in your app's config files and built binaries, so changing it would break apps you've already released. Settle on it before you register.

Examples: acme-learning-app, acme-mobile, acme-intranet-sync

Permissions for this app (scopes)

Shown on the form as Permissions for this app (このアプリに許可する操作). This sets the maximum the app is allowed to request. For details, see Choosing Scopes.

Scopes for member data, reports, webhooks, content editing and app management (read:members, write:members, read:reports, webhooks:manage, write:content, apps:manage) can be granted only by an organization administrator. They're marked Org admins only (組織管理者のみ). If you only have the developer role, these checkboxes appear disabled (any that an administrator has already granted stay as they are).

Redirect URIs

Shown on the form as Redirect URIs (リダイレクト URI). These are the URLs users are sent back to after signing in. Enter one per line.

They're matched exactly. Scheme, host, port, path, even a trailing slash: if a single character differs, the request is rejected. Prefix matching and wildcards aren't supported.

This isn't strictness for its own sake; it's for safety. With loose matching, an attacker could take an app registered as https://app.example.com, send users to https://app.example.com.attacker.test, and steal their authorization codes.

Registered value	Value sent	Result
`acme://auth/callback`	`acme://auth/callback`	Match
`acme://auth/callback`	`acme://auth/callback/`	No match (trailing slash)
`https://a.example/cb`	`http://a.example/cb`	No match (http vs. https)
`http://localhost:8100/cb`	`http://localhost:3000/cb`	No match (port)

If you use local URLs during development, register those too (for example, http://localhost:8100/auth/callback).

App type

Shown on the form as App type (アプリの種別).

Public client (公開クライアント)

Mobile apps, desktop apps and SPAs.

Anything you distribute can be taken apart, so it can't keep a secret safe. Instead of a secret, it's protected by a mechanism called PKCE. If you're not sure, choose this one.

Confidential client (機密クライアント)

Apps that run only on your own servers.

These are issued a client secret. Don't use one in code that ships to browsers or mobile devices.

Client secret

When you register a confidential client, its secret is shown once, right after you save. The same happens if you change an existing public client to confidential: a secret is issued when you save and shown once. The edit screen of a confidential app always shows the Regenerate secret (シークレットを再発行) button.

Once you leave that screen, it can never be shown again. We store only a hash of it, so the original value can't be recovered. If you lose it, issue a new one with Regenerate secret (シークレットを再発行) on the app's edit screen. The old secret stops working immediately.

After you register

Once you have a client ID, you can move on to implementing sign-in. See Signing Users In with Their Manabu2 Account.

Two limits to know about

Only members of the organization that registered the app can sign in to it. The client ID appears in redirect URLs, so others can see it, but users from other organizations can't use it to sign in.

Apps registered here can't sign users in by sending their email address and password directly. Use the authorization code flow (the redirect flow) instead. The policy is simple: an app we didn't write shouldn't be trusted with users' passwords.

Deactivating an app

You can switch an app off with the Deactivate (停止) button in the app list. This deactivates the app; it doesn't delete it.

Everyone signed in through the app is signed out
New sign-ins and token refreshes for the app are all refused, and access tokens already issued stop working immediately instead of lasting until they expire
Its settings are kept, so you can turn it back on later

If you suspect the app's keys have leaked, deactivate it first. That ends its sessions immediately, including access tokens already issued, without waiting for any tokens to expire.

Registering an App – Developer Guide