Что значит предоставить доступ к api

Краткое руководство. Настройка приложения для предоставления веб-API

В этом кратком руководстве вы зарегистрируете веб-API с помощью платформы удостоверений Майкрософт и предоставите его клиентским приложениям, добавив пример области. Зарегистрировав веб-API и предоставив к нему доступ через области, вы можете дать доступ к его ресурсам на основе разрешений полномочным пользователям и клиентским приложениям, обращающимся к API.

Предварительные требования

Регистрация веб-API

Чтобы предоставить в вашем веб-API доступ к ресурсам по областям, сначала необходимо зарегистрировать API с помощью платформы удостоверений Майкрософт.

Зарегистрировав веб-API, вы можете добавлять области, которые код API может использовать для предоставления детализированных разрешений для потребителей API.

Добавление области

Код в клиентском приложении запрашивает разрешение на выполнение операций, определенных веб-API, передавая маркер доступа вместе с его запросами к защищенному ресурсу (веб-API). Затем веб-API выполняет запрошенную операцию, только если полученный маркер доступа содержит области, необходимые для операции.

Для начала выполните указанные ниже действия, чтобы создать пример области с именем Employees.Read.All :

Если у вас есть доступ к нескольким клиентам, в верхнем меню используйте фильтр Каталог и подписка, чтобы выбрать клиент, содержащий регистрацию клиентского приложения.

Выберите Azure Active Directory Регистрация приложений, а затем — регистрацию приложения API.

Выберите Предоставление API Добавить группу.

Вам будет предложено задать URI идентификатора приложения, если он еще не настроен.

Дополнительные сведения о допустимых шаблонах URI идентификатора приложения см. в статье Справочник по манифесту приложения Azure AD.

Затем укажите атрибуты области на панели Добавить группу. В этом пошаговом руководстве вы можете использовать примеры значений или указать собственные.

Задайте параметру Состояние значение Включено, а затем выберите Добавить область.

(Необязательно.) Чтобы отключить запрос согласия пользователей вашего приложения к определенным областям, можно выполнить предварительную авторизацию клиентского приложения для доступа к веб-API. Выполните предварительную авторизацию только тех клиентских приложений, которым вы доверяете, так как у пользователей не будет возможности отклонить согласие.

Если вы выполнили необязательный шаг, клиентское приложение теперь является предварительно авторизованным (PCA) и пользователи не получат запрос на согласие при выполнении входа.

Добавление области, требующей согласие администратора

Проверка предоставленных областей

Если вы успешно добавили оба примера областей, описанные в предыдущих разделах, они отобразятся в области Предоставление API регистрации приложения веб-API, как показано на следующем рисунке:

Как показано на рисунке, полной строкой области является объединение URI идентификатора приложения веб-API и имени области.

Использование предоставленных областей

В следующей статье этой серии вы настроите регистрацию клиентского приложения с доступом к своему веб-API и областям, определенным вами в этой статье.

После того как для регистрации клиентского приложения предоставлено разрешение на доступ к веб-API, клиенту может быть выдан маркер доступа OAuth 2.0 платформы удостоверений Майкрософт. Во время вызова веб-API клиент предоставляет маркер доступа с утверждением области ( scp ), для которого заданы разрешения, указанные в регистрации клиентского приложения.

Позднее вы можете по мере необходимости предоставлять дополнительные области доступа. Помните о том, что веб-API может предоставлять несколько областей, связанных с рядом операций. Ресурс может управлять доступом к веб-API в среде выполнения, вычисляя утверждения области ( scp ) в полученном маркере доступа OAuth 2.0.

Дальнейшие действия

Теперь, когда вы предоставили свой веб-API, настроив его области, выполните настройку регистрации клиентского приложения с разрешением на доступ к этим областям.

Источник

Что такое API (программный интерфейс приложения)?

Программный интерфейс приложения, или интерфейс прикладного программирования (API) – это код, который позволяет двум программам взаимодействовать друг с другом. API определяет правильный способ для разработчика запрашивать службы из операционной системы (ОС) или другого приложения и предоставлять данные в разных контекстах и по нескольким каналам. На заре Web 2.0 концепция интеграции данных и приложений из разных источников называлась mashup.

Любыми данными можно поделиться с помощью программного интерфейса приложения. API реализуются вызовами функций, состоящих из глаголов и существительных; требуемый синтаксис описан в документации вызываемого приложения. Например, на веб-сайте недвижимости один API может публиковать доступные объекты недвижимости по географическому признаку, в то время как второй API предоставляет посетителю текущие процентные ставки, а третий API предлагает калькулятор ипотеки.

Интернет, программное обеспечение, предназначенное для обмена информацией через Интернет, и облачные вычисления – все это вместе повысило интерес к API в целом и к услугам в частности.

Как работают API?

API-интерфейсы состоят из двух связанных элементов. Первый – это спецификация, описывающая, как происходит обмен информацией между программами в форме запроса на обработку и возврата необходимых данных. Второй – это программный интерфейс, написанный в соответствии с этой спецификацией и каким-то образом опубликованный для использования.

Считается, что программное обеспечение, которое хочет получить доступ к функциям и возможностям API, «вызывает» его, а программное обеспечение, которое создает API, «публикует» его.

API-интерфейсы авторизуют и предоставляют доступ к данным, которые запрашиваются пользователями и другими приложениями. Доступ аутентифицируется для службы или части функциональных возможностей по предопределенным ролям, которые определяют, кто или какая служба может получить доступ к определенным действиям или данным. API также предоставляют контрольный журнал, в котором подробно описывается доступ к системе: кто или что и когда.

Приложения, вызывающие API, традиционно писались на определенных языках программирования. Веб-API можно вызывать через любой язык программирования, но также можно получить доступ к веб-страницам, созданным в HTML или инструментах генератора приложений.

Наиболее распространенными архитектурами API являются передача репрезентативного состояния (REST) и простой протокол доступа к объектам (SOAP), который определяет стандартную спецификацию протокола связи для обмена сообщениями на основе XML. SOAP требует меньше кода, связанного с инфраструктурой низкого уровня, чем REST, но REST API легче масштабировать и повторно развертывать, проще реализовать и интегрировать с веб-сайтами и службами. Текущая отраслевая тенденция в основном заключается в использовании REST API, особенно для веб-взаимодействий.

Почему API важны для бизнеса

API-интерфейсы неуклонно улучшают качество и доставку программного обеспечения и услуг. Программное обеспечение, которое было специально разработано для определенной цели, теперь часто пишется для справочных API, которые предоставляют широко полезные функции. Это сокращает время и стоимость разработки, а также снижает риск ошибок.

Растущее количество веб-сервисов, предоставляемых через API-интерфейсы поставщиками облачных услуг, также поощряет создание приложений для облачных вычислений, усилия в области Интернета вещей (IoT) и приложений для поддержки мобильных устройств и пользователей.

API-интерфейсы добавляют цифровой уровень для представления данных и корпоративных активов компании через API-интерфейсы с необходимым управлением и безопасностью, и это может улучшить взаимодействие с клиентами, сотрудниками и партнерами. Большая функциональность и объем услуг увеличивают ценность, предоставляемую пользователям, и улучшают качество обслуживания клиентов – например, вышеупомянутый веб-сайт, который предвосхищает потребности клиентов, связанные с поиском недвижимости.

API-интерфейсы также создают новые возможности монетизации для бизнеса, такие как производство данных с помощью настраиваемых пакетов и планов для новых или существующих деловых партнеров.

Каковы преимущества использования API?

API-интерфейсы – это, по сути, набор правил. Они могут улучшить внутренние процессы разработки организации за счет стандартизации того, как разработчики пишут код приложения – использование одних и тех же правил и форматов делает код более оптимизированным и прозрачным. Стандартизация также облегчает сотрудничество между разработчиками при создании программных компонентов с целью интеграции с API. Это, в свою очередь, может поддержать разработку функций и сократить время вывода продукта на рынок.

Публичные и партнерские API дают организациям:

Поскольку API-интерфейсы основаны на стандартизации, разработка API-интерфейсов может быть сложной и дорогостоящей для интеграции с системами и данными, которые они представляют. Определенные типы функций или действий могут быть лучше решены с помощью дополнительных процессов автоматизации роботизированных процессов (RPA).

Типы API

Существует четыре основных типа API-интерфейсов: частные, общедоступные, партнерские и составные.

API могут быть дополнительно классифицированы как локальные, веб-интерфейсы или программные API.

Почему дизайн API так важен

Хороший дизайн API имеет решающее значение для успешного использования API, и архитекторы программного обеспечения тратят много времени на изучение всех возможных приложений API и наиболее логичного способа его использования.

Структуры данных и значения параметров имеют особое значение, поскольку они должны совпадать между вызывающим API и его издателем.

Безопасность – важный аспект разработки API. Использование неверно настроенных API-интерфейсов – обычная практика для кибер-злоумышленников. API-интерфейсы – это шлюз, который представляет системы и данные организации внутренним и внешним пользователям – любой взлом может создать серьезные проблемы безопасности.

Какие есть примеры API?

Многие программные продукты и инструменты предоставляют функциональные возможности через API, от инструментов DevOps, таких как Docker, Jenkins и GitlLab, до корпоративных платформ, таких как Microsoft Sharepoint. Социальные сети, в частности, используют преимущества открытых API-интерфейсов для поддержки сторонних функций, таких как возможность создавать новостные ленты и обмениваться фотографиями.

Интернет в настоящее время является основным двигателем для API-интерфейсов, и такие компании, как Facebook, Google и Yahoo, публикуют API-интерфейсы, чтобы побудить сторонних разработчиков использовать свои возможности. Эти API-интерфейсы предоставили нам все: от новых интернет-функций, которые позволяют просматривать сайты других сервисов, до приложений для мобильных устройств, обеспечивающих легкий доступ к веб-ресурсам. Новые функции, такие как доставка контента, дополненная реальность и новые приложения носимых устройств, в значительной степени создаются с помощью этих API.

Тенденции API

Повсеместное распространение Интернета, более широкое использование облачных вычислений и переход от монолитных приложений к микросервисам – все это способствовало широкому распространению API.

REST и Web

Веб-API можно вызывать через любой язык программирования, но также можно получить доступ к веб-страницам, созданным в HTML или инструментах генератора приложений. Возросшая роль Интернета и облака в нашей жизни и деловой активности значительно расширила использование API-интерфейсов и использование простых инструментов программирования или даже отказа от программирования для доступа к API.

И REST, и SOAP могут вызывать облачные сервисы, подключаться к ним и взаимодействовать с ними, но REST все чаще предпочтительнее для веб-API, поскольку он использует меньшую пропускную способность и предлагает больше возможностей для языков программирования, таких как JavaScript или Python. Крупные веб-сайты, такие как Amazon, Google, LinkedIn и Twitter, используют RESTful API.

API и облако

Облачные вычисления предоставляют новые возможности для разделения программного обеспечения на повторно используемые компоненты, подключения компонентов к запросам и увеличения количества копий программного обеспечения по мере изменения спроса.

Эти облачные возможности сместили фокус API-интерфейсов с простых моделей, ориентированных на RPC-программиста, на веб-модели RESTful и даже на то, что называется «функциональным программированием» или «лямбда-моделями» сервисов, которые можно мгновенно масштабировать по мере необходимости в облако.

API как сервисы

Тенденция рассматривать API как представление общих ресурсов изменилась. В то время как ожидается, что API-интерфейсы будут использоваться в качестве общего инструмента многими приложениями и пользователями, они считаются службами и обычно требуют более контролируемой разработки и развертывания.

SOA и микросервисы являются примерами сервисных API. Сервисы – самая горячая тенденция в API, до такой степени, что возможно, что все API в будущем будут рассматриваться как представляющие сервисы.

Публикация и управление API

Компания, которая публикует API, контролирует его использование, от безопасности до надежности и взимания платы за использование. Он также контролирует добавление функций, выполняемых компанией или третьими сторонами. Это означает, что компания должна поддерживать производительность API в соответствии со своими условиями обслуживания, как и с любым приложением или услугой.

Тестирование API

Как и все программное обеспечение, API-интерфейсы необходимо тестировать. Тестирование проверяет опубликованные API-интерфейсы на соответствие спецификациям, которые пользователи этих API-интерфейсов используют для форматирования своих запросов. Тестирование API также гарантирует, что:

Тестирование API обычно выполняется как часть управления жизненным циклом приложения (ALM) как для программного обеспечения, которое публикует API, так и для всего программного обеспечения, которое их использует. API-интерфейсы также должны быть протестированы в их опубликованной форме, чтобы убедиться, что к ним можно получить надлежащий доступ.

Управление API

Управление API относится к набору действий, связанных с публикацией API для использования, что позволяет пользователям находить его и его спецификации и регулировать доступ к API на основе определенных владельцем разрешений или политик.

Управление API стало распространенным явлением, поскольку предприятия все больше зависят от API, принимают больше из них и справляются с административными сложностями, которые вносят API. Потребности в управлении API могут отличаться от организации к организации, но обычно включают некоторые базовые функции, включая безопасность, управление, аналитику и контроль версий.

API-интерфейсы требуют тщательной документации, повышенного уровня безопасности, всестороннего тестирования, регулярного управления версиями и высокой надежности. Чтобы удовлетворить эти строгие требования, организации используют программное обеспечение для управления API, либо в виде комбинированной платформы, либо с помощью отдельных инструментов. Обычно они включают несколько основных компонентов: портал разработчика API, управление жизненным циклом API, менеджер политик API, аналитику API и шлюз API.

Интернет-предприниматель, специалист по SEO и SMM, E-commerce, вебмастер, блогер.

Источник

Краткое руководство. Настройка клиентского приложения для доступа к веб-API

В этом кратком руководстве вы предоставляете клиентское приложение, зарегистрированное на платформе удостоверений Microsoft, с ограниченным доступом на основе разрешений к своему веб-API. Вы также предоставляете клиентскому приложению доступ к Microsoft Graph.

Если при регистрации клиентского приложения указать области веб-API, клиентское приложение может получить маркер доступа, содержащий эти области, из платформы удостоверений Microsoft. В своем коде веб-API может предоставлять доступ к своим ресурсам на основе разрешений с учетом областей, указанных в маркере доступа.

Предварительные требования

Добавление разрешений для доступа к веб-API

В первом сценарии вы предоставляете клиентскому приложению доступ к вашему веб-API, который должен быть предварительно зарегистрирован. Если у вас еще нет зарегистрированных клиентского приложения и веб-API, выполните действия, описанные в двух статьях Предварительные требования.

На этой схеме показано, как регистрации двух приложений связаны друг с другом. В этом разделе вы добавите разрешения в регистрацию клиентского приложения.

После регистрации клиентского приложения и веб-API и предоставления API путем создания областей можно настроить клиентские разрешения для API, выполнив следующие действия.

Если у вас есть доступ к нескольким клиентам, в верхнем меню используйте фильтр Каталог и подписка, чтобы выбрать клиент, содержащий регистрацию клиентского приложения.

Выберите Azure Active Directory Регистрация приложений, а затем выберите свое клиентское приложение (а не свой веб-API).

Выберите Разрешения API Добавить разрешение Мои API.

Выберите предварительно зарегистрированный веб-API.

Параметр Делегированные разрешения выбран по умолчанию. Делегированные разрешения подходят для клиентских приложений, которые обращаются к веб-API в качестве пользователя, выполнившего вход, и доступ которых должен быть ограничен разрешениями, выбираемыми на следующем шаге. Для этого примера оставьте параметр Делегированные разрешения выбранным.

Параметр Разрешения приложения предназначен для приложений типа службы или управляющей программы, которым необходим доступ к веб-API без участия пользователя при входе или предоставлении согласия. Пока вы не определите роли приложений для веб-API, этот параметр будет отключен.

В разделе Выбор разрешений разверните ресурс, области которого определены для веб-API, и выберите разрешения, которым клиентское приложение должно обладать от имени пользователя, выполнившего вход.

Если вы использовали примеры имен областей, указанные в предыдущем кратком руководстве, вы увидите имена Employees.Read.All и Employees.Write.All. Выберите Employees.Read.All или другое разрешение, которое могло быть создано заранее.

Чтобы завершить процесс, выберите Добавление разрешений.

После добавления разрешений в API вы увидите выбранные разрешения в разделе Настроенные разрешения. На следующем рисунке показан пример делегированного разрешения Employees.Read.All, добавленного в регистрацию клиентского приложения.

Вы также можете увидеть разрешение User.Read для API Microsoft Graph. Это разрешение добавляется автоматически при регистрации приложения на портале Azure.

Добавление разрешений для доступа к Microsoft Graph

Помимо доступа к вашему веб-API от имени пользователя, выполнившего вход, приложению также может потребоваться доступ к данным этого (или другого) пользователя, хранящимся в Microsoft Graph, или их изменение. Возможно, у вас есть приложение в виде службы или управляющей программы, которому требуется доступ к Microsoft Graph от своего имени для выполнения операций без вмешательства пользователя.

Делегированное разрешение для Microsoft Graph

Настройте делегированное разрешение для Microsoft Graph, чтобы разрешить клиентскому приложению выполнять операции от имени вошедшего в систему пользователя, например читать электронную почту или изменять профиль. По умолчанию у пользователя клиентского приложения при входе в систему запрашивается согласие на делегированные разрешения, которые вы настроили для него.

Если у вас есть доступ к нескольким клиентам, в верхнем меню используйте фильтр Каталог и подписка, чтобы выбрать клиент, содержащий регистрацию клиентского приложения.

Выберите Azure Active Directory Регистрация приложений, а затем выберите свое клиентское приложение.

Выберите Разрешения API Добавить разрешение Microsoft Graph

Нажмите Делегированные разрешения. Microsoft Graph предоставляет множество разрешений, наиболее часто используемые из которых отображаются в верхней части списка.

В разделе Выбор разрешений выберите следующие разрешения.

Чтобы завершить процесс, выберите Добавление разрешений.

После настройки разрешений пользователи приложения при входе получают запрос, чтобы разрешить приложению доступ к API ресурса от их имени.

Администратор может также предоставить согласие от имени сразу всех пользователей, чтобы они не получали запрос вообще. Согласие администратора обсуждается далее в разделе Дополнительные сведения о разрешениях API и согласии администратора этой статьи.

Разрешение приложения для Microsoft Graph

Настройте разрешения для приложения, которое должно проходить проверку подлинности без участия пользователя или его согласия. Разрешения приложения обычно используются фоновыми службами или управляющими программами, которые обращаются к API в режиме без монитора, и веб-API, которые обращаются к другому (подчиненному) API.

В последующих шагах в качестве примера вы предоставляете разрешение Files.Read.All Microsoft Graph.

Если у вас есть доступ к нескольким клиентам, в верхнем меню используйте фильтр Каталог и подписка, чтобы выбрать клиент, содержащий регистрацию клиентского приложения.

Выберите Azure Active Directory Регистрация приложений, а затем выберите свое клиентское приложение.

Выберите Разрешения API Добавить разрешение Microsoft Graph Разрешения приложения.

Все разрешения, предоставляемые Microsoft Graph, отображаются в разделе Выбор разрешений.

Выберите разрешение или разрешения, которые вы хотите предоставить приложению. Например, вы можете использовать управляющее приложение, которое сканирует файлы в вашей организации, уведомляя об определенном типе или имени файла.

В разделе Выбор разрешения разверните Файлы, а затем выберите разрешение Files.Read.All.

Выберите Добавить разрешения.

Некоторые разрешения, такие как разрешение Microsoft Graph Files.Read.All, требуют согласия администратора. Чтобы предоставить согласие администратора, выберите Предоставление согласия администратора, как описано далее в разделе Кнопка «Согласие администратора».

Настройка учетных данных клиента

Приложения, использующие разрешения приложения, проходят проверку подлинности самостоятельно, используя собственные учетные данные, без вмешательства пользователя. Прежде чем приложение (или API) сможет получить доступ к Microsoft Graph, вашему веб-API или другому API с помощью разрешений приложения, необходимо настроить учетные данные клиентского приложения.

Дополнительные сведения о разрешениях API и согласии администратора

Панель Разрешения API для регистрации приложения содержит таблицу Настроенные разрешения, а также может содержать таблицу Другие предоставленные разрешения. Обе таблицы и кнопка согласия администратора описаны в следующих разделах.

Настроенные разрешения

В таблице Настроенные разрешения на панели Разрешения API отображается список разрешений, необходимых приложению для базовой работы — список требуемого доступа к ресурсам. Пользователям или их администраторам необходимо согласиться с этими разрешениями перед использованием приложения. Кроме того, позже во время выполнения могут запрашиваться дополнительные разрешения (с использованием динамического согласия).

Это минимальный список разрешений, которые должны быть предоставлены пользователями вашему приложению. Их может быть больше, но эти всегда будут обязательно. Для обеспечения безопасности и, чтобы помочь пользователям и администраторам комфортнее работать с приложением, не следует запрашивать ничего, что вам не понадобиться.

Разрешения, отображаемые в этой таблице, можно добавить или удалить, выполнив описанные выше действия или указания из раздела Другие предоставленные разрешения (ниже). Администратор может предоставить согласие администратора для всех разрешений API, отображаемых в таблице, и отозвать согласие на индивидуальные разрешения.

Другие предоставленные разрешения

Кроме того, вы можете увидеть таблицу Другие предоставленные разрешения для на панели Разрешения API. В таблице Другие предоставленные разрешения для показаны предоставленные арендатору разрешения, которые не были настроены явно на объекте приложения. Для этих разрешений администратором от имени всех пользователей были динамически выполнены запросы и предоставлено согласие. Этот раздел отображается, только если имеется хотя бы одно подходящее разрешение.

Можно добавить полный набор разрешений API или отдельные разрешения, отображаемые в этой таблице, в таблице Настроенные разрешения. Администратор может отозвать согласие для API или отдельных разрешений в этом разделе.

Кнопка согласия администратора

Кнопка Предоставление согласия администратора для позволяет администратору предоставить согласие администратора для разрешений, настроенных для приложения. После нажатия кнопки отображается диалоговое окно с запросом на согласие выполнить действие.

После предоставления согласия разрешения, для которых необходимо предоставить согласие администратора, показаны как разрешения с предоставленным согласием.

Кнопка Предоставить согласие администратораотключена, если вы не являетесь администратором или если для приложения не настроены разрешения. Если у вас есть разрешения, которые были предоставлены, но еще не настроены, кнопка согласия администратора поможет вам их обработать. Их можно добавить в настроенные разрешения или удалить.

Дальнейшие действия

Перейдите к следующему краткому руководству в серии, чтобы узнать, как настроить доступ к приложению для определенных типов учетных записей. Например, вы можете предоставить доступ только пользователям в организации (один арендатор) или разрешить доступ пользователям из других арендаторов Azure AD (несколько арендаторов) и пользователям с личными учетными записями Майкрософт (MSA).

Источник