Области используются для определения того, какие приложения могут действовать от имени владельца ресурса.
Если у вас есть приложение, скажем, служба голосования, по адресу survey.example.com. У вас есть две роли: избиратели, которые могут видеть опрос, и голосование, и администраторы, которые могут видеть полные результаты. Приложение для голосования применяет разрешения на основе этих ролей. Локальному пользователю назначается локальная роль. Приложение защищено с помощью OAuth, поэтому пользователь может быть идентифицирован токеном.
У вас также есть приложение для социальной сети social.example.com. Это приложение предоставляет страницу, где пользователи могут голосовать в службе голосования. Он также подключен к тому же серверу авторизации OAuth.
Наконец, у кого-то есть приложение для создания отчетов, reports.example.com. Это приложение хотело бы позволить пользователям видеть подсчет голосов, запрашивая его у службы голосования. Он подключен к тому же серверу авторизации.
Сервер авторизации, скажем, iam.example.com. Сервер авторизации имеет три клиента, по одному для каждого приложения, описанного выше. На сервере авторизации определены две области: voting и reporting.
Приложение создания отчетов, когда вы входите в систему, запросит область действия reporting. Фактический вход происходит на iam.example.com, который предоставит токен для reports.example.com. Форма входа в систему спросит вас, пользователя, предоставляете ли вы клиенту (reports.example.com) право действовать от вашего имени и получать отчеты из службы голосования (предоставляемой областью действия reports). Область будет записана и сопоставлена с токеном, который она отправляет на reports.example.com.
Теперь приложение для создания отчетов может отправить запрос на poll.example.com, который говорит: «Я хотел бы увидеть голосование подсчет "Приложение голосования.example.com проверит токен и при условии, что у него есть область действия reports, оно отправит подсчет обратно.
Если оно попытается сделать запрос в службу голосования для голосования , он должен быть отклонен с помощью voice.example.com, поскольку токен на предъявителя не имеет области, позволяющей вам голосовать. Это должно быть обеспечено приложением для голосования. Сервер авторизации определяет, какому клиенту предоставлена какая область. Только чтобы увидеть отчеты. Это не связано с вашей ролью в самом приложении для голосования.
Сам по себе OAuth не предоставляет механизм проверки личности, поэтому у вас нет механизма для проверки того, кто вы по токену и какие роли у тебя есть. OpendID connect (OID C) обеспечивает дополнительную функциональность для этого, предоставляя конечную точку идентификации на основе области действия, защищенную конечной точкой авторизации, которая позволяет ему раскрывать вашу личность приложению. Поэтому, если мы предположим, что у вас тоже есть OID C, то по токену он проверит, кто вы. Затем он может проверить свою базу данных, чтобы выяснить, есть ли у вас нужная роль, и разрешено ли вам просматривать счет перед отправкой.
Что обеспечивает область действия, так это то, что приложение отчетов, используя свой клиент, может получить токен, который будет действовать от вашего имени и запросить информацию. Когда вы предоставляете клиенту область действия, вы разрешаете ему общаться со службой голосования для получения информации.
Роли управляются вашим приложением и с помощью системы разрешений определяют, кто может голосовать, кто может читать голосов.
Используя что-то вроде OID C, вы можете расширить OAuth, чтобы токен идентифицировал вас. www.investment.example.com может проверить, что вы а) уполномочены голосовать (по локальной логике c), б) что приложению, действующему от вашего имени, разрешено действовать от вашего имени (через область действия, прикрепленную к маркер).