Spring Securityのロール・権限・スコープの違いとは？初心者向けに権限設計の基本を解説！

1. Spring Securityで使われる3つの用語とは？

1. Spring Securityで使われる3つの用語とは？

Spring Securityでは、ユーザーのアクセス制御を行うために「ロール」「権限」「スコープ」という用語がよく使われます。これらの違いをきちんと理解することで、セキュリティの設計がスムーズになります。

• ロール（Role）：ユーザーの役割。管理者や一般ユーザーなど。
• 権限（Authority）：操作の許可。特定の機能へのアクセスなど。
• スコープ（Scope）：OAuth2などで使用。アクセス可能なリソースの範囲。

2. ロール（ROLE_）とは何か？

2. ロール（ROLE_）とは何か？

ロールは、ユーザーの「役割」を示します。Spring Securityでは、ROLE_ADMINやROLE_USERのように、プレフィックスとしてROLE_が付きます。これはSpring Securityが内部的にロールと権限を区別するためのルールです。

以下はロールに基づいてアクセス制御する例です。

http
    .authorizeHttpRequests(auth -> auth
        .requestMatchers("/admin/**").hasRole("ADMIN")
        .requestMatchers("/user/**").hasAnyRole("USER", "ADMIN")
        .anyRequest().authenticated()
    );

このように、ロールは大まかな分類であり、「どの機能を使えるか」の判断材料になります。

3. 権限（Authority）の考え方

3. 権限（Authority）の考え方

権限は、ロールよりも細かい粒度でアクセス制御を行うために使われます。READ_ARTICLEやEDIT_USERなど、操作そのものを指すケースが多いです。

http
    .authorizeHttpRequests(auth -> auth
        .requestMatchers("/articles/edit").hasAuthority("EDIT_ARTICLE")
        .anyRequest().authenticated()
    );

ロールと違い、プレフィックスROLE_は不要です。また、ロールは権限の集合と捉えることもできます。

4. スコープ（Scope）の役割

4. スコープ（Scope）の役割

スコープは主にOAuth2で登場します。APIアクセスにおいて、「何ができるか」を限定するための情報です。例えば、read:userやwrite:articleのように記述されます。

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .oauth2ResourceServer(oauth2 -> oauth2
            .jwt(jwt -> jwt
                .jwtAuthenticationConverter(converter())
            )
        );
    return http.build();
}

このように、JWTトークン内のscopeクレームをSpring Securityで検証して、アクセス制御に利用することができます。

5. ベストプラクティス：ロール・権限の設計ルール

5. ベストプラクティス：ロール・権限の設計ルール

初心者が陥りがちなのが、すべての制御をロールで済ませようとすることです。しかし、以下のようなルールに従うことで、将来的に柔軟な運用が可能になります。

• ロールは大まかな分類（例：ROLE_ADMIN）
• 権限は操作レベルで定義（例：CREATE_ORDER, DELETE_USER）
• ロールに権限を束ねる（ROLE_ADMIN → 全権限を含む）

このように分離しておけば、新しい操作が追加されても権限単位で柔軟に対応できます。

6. @PreAuthorizeでの権限チェック

6. @PreAuthorizeでの権限チェック

Spring Securityでは、@PreAuthorizeアノテーションを使って、メソッド単位の権限制御も可能です。以下はその例です。

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long userId) {
    // 管理者だけが実行可能
}

より細かくしたい場合は、権限を使った制御もできます。

@PreAuthorize("hasAuthority('EDIT_PROFILE')")
public void updateProfile(User user) {
    // 権限を持っていればOK
}

7. カスタムのロールと権限を設定する方法

7. カスタムのロールと権限を設定する方法

カスタムでロールや権限を設計するには、UserDetailsのgetAuthoritiesメソッドで必要な情報を返すようにします。

@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
    return List.of(
        new SimpleGrantedAuthority("ROLE_USER"),
        new SimpleGrantedAuthority("EDIT_PROFILE")
    );
}

このようにしておけば、柔軟にロールと権限をミックスしたアクセス制御が可能になります。

8. 実務でよくある失敗と設計のコツ

8. 実務でよくある失敗と設計のコツ

以下は実務でありがちな失敗例です。

• 全機能をROLE_ADMINで制御し、運用が複雑になる
• APIとWebでスコープと権限が混在して混乱する
• ロール名に操作名を含めてしまい、拡張性がなくなる

これらを防ぐためには、役割と操作の設計をきっちり分けておくことが大切です。たとえば以下のようなマッピングルールが現場でよく使われます。

ROLE_ADMIN → 全権限
ROLE_EDITOR → READ_ARTICLE, EDIT_ARTICLE
ROLE_VIEWER → READ_ARTICLE