- "auth" という用語は、認証(authentication)と認可(authorization)の2つの意味を持つ
- そのため、ライブラリ名やパッケージ名で混乱が生じる
- "authn" と "authz" という用語は明確ではなく、理解しにくい
認証と認可の違い
- 認証(authentication): ユーザーが誰であるかを確認するプロセス
- 認可(authorization): ユーザーが何をできるかを決定するプロセス
- 2つの概念は互いに異なり、片方を解決してももう片方の問題が解決するわけではない
"permissions" と "login" の使用提案
- 認証は "login"、認可は "permissions" として明確に区別することを提案
- "login" は名詞形と動詞形の両方で使える
- 名詞: システムにアクセスするために入力する情報
- 動詞: システムを使うためにログインする行為
- "permissions" は名詞形で使い、動詞形としては "check permissions" を使う
明確な用語を使う利点
- ソフトウェアエンジニア以外の分野の人にも理解しやすい
- より良い抽象化が可能になる
- 認証と認可を別々のモジュールとして分離して設計できる
GN⁺ の意見
- 明確な用語を使う重要性: 用語が明確であればコミュニケーションが円滑になり、誤解を減らせる。
- 抽象化の利点: 認証と認可を分離すると、システム設計がより柔軟になり、保守もしやすくなる。
- 他の用語の使用例: "login" や "permissions" のほかに、"access control" のような用語も検討に値する。
- 技術導入時の考慮事項: 新しい用語を導入する際は、チーム内で十分な議論と合意が必要。
- 関連プロジェクトの紹介: 認証と認可を分離した代表的なプロジェクトとして、OAuth と OpenID Connect がある。
8件のコメント
開発者同士では
authの代わりにauthn,authzを使い、ユーザーとの接点があるドキュメントやコントローラー／ファサードではlogin,permissionを使う、というのは同意できます。ただ、authn,authzまでなくそうというのは、そこまでする必要があるのかなと思います。本文で指摘されているように、
authは認証と権限の両方を曖昧に指す形で使われていて、たしかに混乱しがちでしたね。純粋な開発者以外の分野とのコミュニケーションのためにも、より一般的な用語で分けるのは望ましい試みだと思います。Authentication と Authorization の両方を Auth と略せてしまうのが問題なら、
本文で言及されていたように Authn、Authz で十分な気もしますが……
これでは明確ではないと考えたなら、Authenty、Authory くらいまで少し長くしてもよいでしょう。
権限システムにもパーミッション方式があって、ACL方式もあって、ではそれをどう区別しようというのか……？
なんだかこじつけっぽいですね……
おそらく非開発チームのメンバーとのコミュニケーションコストを下げようという試みなのだと思いますが、少しやりすぎですね。
わざわざ両方を合わせて auth と呼んでいるのではないですか？
Authentication と authorization があるのに、なぜわざわざ…
Hacker Newsの意見