что такое redirect uri

Что такое redirect uri

Для приложений на iOS, Android, Windows Phone мы рекомендуем использовать упрощенную схему авторизации через SDK.

Необходимо перенаправить браузер пользователя по адресу
https://oauth.vk.com/authorize, передав следующие параметры:

Redirect_uri — это URL, на который будет переадресован браузер пользователя после разрешения им прав доступа.

Если Вы разрабатываете веб-приложение и хотите работать с API из Javascript, в redirect_uri необходимо указать адрес страницы на Вашем сайте. В целях безопасности, этот адрес также должен быть указан в настройках Вашего приложения (поля «Адрес сайта», «Базовый домен» и «Доверенный Redirect URI»).

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

Во всех остальных случаях (мобильное, десктопное приложение) необходимо использовать redirect_uri по умолчанию: https://oauth.vk.com/blank.html

Если пользователь не авторизован ВКонтакте в используемом браузере, то в диалоговом окне ему будет предложено ввести свой логин и пароль.

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

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

Обратите внимание, что некоторые права могут быть запрошены только Standalone-приложением (например, право доступа messages). Это автоматически означает необходимость использования redirect_uri по умолчанию (см. redirect_uri).

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

Вместе с ключом access_token также будет указано время его жизни expires_in, заданное в секундах. expires_in содержит 0, если токен бессрочный (при использовании scope = offline). Если срок использования ключа истек, то необходимо повторно провести все описанные выше шаги, но в этом случае пользователю уже не придется дважды разрешать доступ. Запрашивать access_token также необходимо при смене пользователем логина или пароля или удалением приложения в настройках доступа.

Кроме того, среди возвращаемых параметров будет указан user_id — идентификатор авторизовавшегося пользователя.

В случае возникновения ошибки авторизации в качестве GET-параметров в redirect_uri будет передана информация об этой ошибке.

Источник

OAuth 2.0 простым и понятным языком

На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.

Что такое OAuth 2.0

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

Чем отличаются OpenID и OAuth

Не смотря на то, что объяснений на эту тему уже было много, она по-прежнему вызывает некоторое непонимание.

OpenID предназначен для аутентификации — то есть для того, чтобы понять, что этот конкретный пользователь является тем, кем представляется. Например, с помощью OpenID некий сервис Ололо может понять, что зашедший туда пользователь, это именно Рома Новиков с Mail.Ru. При следующей аутентификации Ололо сможет его опять узнать и понять, что, это тот же Рома, что и в прошлый раз.

OAuth же является протоколом авторизации, то есть позволяет выдать права на действия, которые сам Ололо сможет производить в Mail.Ru от лица Ромы. При этом Рома после авторизации может вообще не участвовать в процессе выполнения действий, например, Ололо сможет самостоятельно заливать фотографии на Ромин аккаунт.

Как работает OAuth 2.0

Как и первая версия, OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров…

Ключевое отличие от OAuth 1.0 — простота. В новой версии нет громоздких схем подписи, сокращено количество запросов, необходимых для авторизации.

Авторизация для приложений, имеющих серверную часть

Пример

Здесь и далее примеры приводятся для API Mail.Ru, но логика одинаковая для всех сервисов, меняются только адреса страниц авторизации. Обратите внимание, что запросы надо делать по HTTPS.

Редиректим браузер пользователя на страницу авторизации:

Здесь и далее, client_id и client_secret — значения, полученные при регистрации приложения на платформе.

После того, как пользователь выдаст права, происходит редирект на указанный redirect_uri:

Обратите внимание, если вы реализуете логин на сайте с помощью OAuth, то рекомендуется в redirect_uri добавлять уникальный для каждого пользователя идентификатор для предотвращения CSRF-атак (в примере это 123). При получении кода надо проверить, что этот идентификатор не изменился и соответствует текущему пользователю.

Используем полученный code для получения access_token, выполняя запрос с сервера:

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

В результате последнего запроса получаем сам ключ доступа (access_token), время его «протухания&raquo (expires_in), тип ключа, определяющий как его надо использовать, (token_type) и refresh_token о котором будет подробнее сказано ниже. Дальше, полученные данные можно использовать для доступа к защищенным ресурсам, например, API Mail.Ru:

Авторизация полностью клиентских приложений

Пример

Открываем браузер со страницей авторизации:

После того, как пользователь выдаст права, происходит редирект на стандартную страницу-заглушку, для Mail.Ru это connect.mail.ru/oauth/success.html:

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

Авторизация по логину и паролю

Авторизация по логину и паролю представляет простой POST-запрос, в результате которого возвращается access token. Такая схема не представляет из себя ничего нового, но вставлена в стандарт для общности и рекомендуется к применению только, когда другие варианты авторизации не доступны.

Пример

Восстановление предыдущей авторизации

Обычно, access token имеет ограниченный срок годности. Это может быть полезно, например, если он передается по открытым каналам. Чтобы не заставлять пользователя проходить авторизацию после истечения срока действия access token‘а, во всех перечисленных выше вариантах, в дополнение к access token‘у может возвращаться еще refresh token. По нему можно получить access token с помощью HTTP-запроса, аналогично авторизации по логину и паролю.

Пример

Минусы OAuth 2.0

Во всей этой красоте есть и ложка дегтя, куда без нее?

OAuth 2.0 — развивающийся стандарт. Это значит, что спецификация еще не устоялась и постоянно меняется, иногда довольно заметно. Так, что если вы решили поддержать стандарт прямо сейчас, приготовьтесь к тому, что его поддержку придется подпиливать по мере изменения спецификации. С другой стороны, это также значит, что вы можете поучаствовать в процессе написания стандарта и внести в него свои идеи.

Безопасность OAuth 2.0 во многом основана на SSL. Это сильно упрощает жизнь разработчикам, но требует дополнительных вычислительных ресурсов и администрирования. Это может быть существенным вопросом в высоко нагруженных проектах.

Заключение

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

Источник

Ограничения для URI перенаправления (URL-адресов ответа)

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

Модель приложения Azure Active Directory (Azure AD) определяет следующие ограничения для URI перенаправления:

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

Максимальное число URI перенаправления

В этой таблице указано максимальное число URI перенаправления, которые можно добавить для зарегистрированного приложения на платформе удостоверений Майкрософт.

Максимальная длина URI

Длина каждого URI перенаправления, добавляемого для зарегистрированного приложения, должна составлять не более 256 символов.

Перенаправление URI в главных объектах приложений и субъектов-служб

Поддерживаемые схемы

HTTPS: схема HTTPS ( https:// ) поддерживается для всех URI перенаправления на базе протокола HTTP.

HTTP: схема HTTP ( http:// ) поддерживается только для URI перенаправления localhost и используется исключительно на этапах локальной разработки и тестирования приложения.

Исключения для localhost

В соответствии с разделами RFC 8252 8.3 и 7.3, для URI перенаправления с замыканием на себя (localhost) действуют два особых правила:

С точки зрения разработки это означает несколько моментов:

Это особенно важно, если вы планируете использовать в одном зарегистрированном приложении разные потоки проверки подлинности (например, и выдачу кода авторизации, и неявный поток). Чтобы связать с каждым URI перенаправления правильные параметры ответа, сервер входа должен иметь возможность различать эти URI, что невозможно, если различается только порт.

IPv6-адрес замыкания на себя ( [::1] ) в настоящее время не поддерживается.

Выбор 127.0.0.1 вместо localhost

При этом текстовое поле URI перенаправления на портал Azure нельзя использовать для добавления URI замыкания на себя со схемой http :

Ограничения на подстановочные знаки в URI перенаправления

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

Чтобы добавить URI перенаправления с подстановочными знаками для зарегистрированных приложений, которые входят в рабочие или учебные учетные записи, используйте редактор манифеста приложения в разделе Регистрация приложений на портале Azure. Хотя с помощью редактора манифеста действительно можно задать URI перенаправления с подстановочными знаками, мы настоятельно рекомендуем придерживаться требований раздела 3.1.2 RFC 6749 и использовать только абсолютные URI.

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

Использование параметра состояния

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

Если вы используете этот подход:

Такой подход позволяет скомпрометированному клиенту изменять дополнительные параметры, отправляемые в параметре состояния, поэтому пользователь перенаправляется на другой URL-адрес, что является угрозой открытого перенаправления, как описано в стандарте RFC 6819. Таким образом, клиент должен защищать эти параметры, шифруя состояние или проверяя его с помощью других средств, таких как проверка доменного имени в URI перенаправления по маркеру.

Источник

Redirect URI (reply URL) restrictions and limitations

A redirect URI, or reply URL, is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it’s important you register the correct location as part of the app registration process.

The Azure Active Directory (Azure AD) application model specifies these restrictions to redirect URIs:

Redirect URIs that contain a path segment are not appended with a trailing slash in the response.

Maximum number of redirect URIs

This table shows the maximum number of redirect URIs you can add to an app registration in the Microsoft identity platform.

Maximum URI length

You can use a maximum of 256 characters for each redirect URI you add to an app registration.

Redirect URIs in application vs. service principal objects

Supported schemes

HTTPS: The HTTPS scheme ( https:// ) is supported for all HTTP-based redirect URIs.

HTTP: The HTTP scheme ( http:// ) is supported only for localhost URIs and should be used only during active local application development and testing.

Localhost exceptions

Per RFC 8252 sections 8.3 and 7.3, «loopback» or «localhost» redirect URIs come with two special considerations:

From a development standpoint, this means a few things:

This is especially important when you want to use different authentication flows in the same application registration, for example both the authorization code grant and implicit flow. To associate the correct response behavior with each redirect URI, the login server must be able to distinguish between the redirect URIs and cannot do so when only the port differs.

The IPv6 loopback address ( [::1] ) is not currently supported.

Prefer 127.0.0.1 over localhost

You cannot, however, use the Redirect URIs text box in the Azure portal to add a loopback-based redirect URI that uses the http scheme:

To add a redirect URI that uses the http scheme with the 127.0.0.1 loopback address, you must currently modify the replyUrlsWithType attribute in the application manifest.

Restrictions on wildcards in redirect URIs

Wildcard URIs like https://*.contoso.com may seem convenient, but should be avoided due to security implications. According to the OAuth 2.0 specification (section 3.1.2 of RFC 6749), a redirection endpoint URI must be an absolute URI.

Wildcard URIs are currently unsupported in app registrations configured to sign in personal Microsoft accounts and work or school accounts. Wildcard URIs are allowed, however, for apps that are configured to sign in only work or school accounts in an organization’s Azure AD tenant.

To add redirect URIs with wildcards to app registrations that sign in work or school accounts, use the application manifest editor in App registrations in the Azure portal. Though it’s possible to set a redirect URI with a wildcard by using the manifest editor, we strongly recommend you adhere to section 3.1.2 of RFC 6749. and use only absolute URIs.

If your scenario requires more redirect URIs than the maximum limit allowed, consider the following state parameter approach instead of adding a wildcard redirect URI.

Use a state parameter

If you have several subdomains and your scenario requires that, upon successful authentication, you redirect users to the same page from which they started, using a state parameter might be helpful.

This approach allows a compromised client to modify the additional parameters sent in the state parameter, thereby redirecting the user to a different URL, which is the open redirector threat described in RFC 6819. Therefore, the client must protect these parameters by encrypting the state or verifying it by some other means, like validating the domain name in the redirect URI against the token.

Next steps

Learn about the app registration Application manifest.

Источник

Understanding the OAuth2 redirect_uri and Azure AD Reply URL Parameters

When you register an Azure AD application, amongst other things you are required to configure a Reply URL, which by default takes its value from the Sign-On URL value you enter during the Azure application registration wizard.

The explanation for the Reply URL parameter is in most cases a little vague…

Reply URL and Redirect URI: In the case of a web API or web application, the Reply URL is the location to which Azure AD will send the authentication response, including a token if authentication was successful

This I find is a rather terse explanation, so I’ll try to explain it with an example using the implicit grant flow, by the way this is true for both the implicit grant flow and the authorization code flow.

My Azure application configuration includes the following Reply URL…

In the authorization URL below (lines breaks included for clarity), you can see that I set the redirect_uri querystring parameter to https://pdogs.azurewebsites.net/callback.html (url encoded).

https://login.microsoftonline.com/1c3d2eea-12db-2ec3-437e-2eec7289e1a1/oauth2/authorize
?client_id=ef92a29b-b332-9d43-1341-23326315fa42
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Fpdogs.azurewebsites.net%2Fcallback.html
&state=12345
&nonce=678910
&resource=https%3A%2F%2Fgraph.microsoft.com%2F

Firstly, the redirect_uri supplied is a specific location in my application where I want Azure, to send the OAuth2 response, which may include an authorization code, an id_token or access_token or both, and in this location (or page) in my application I’ll handle that response in some way.

In the case above, a redirect_uri of https://pdogs.azurewebsites.net/callback.html matches the Reply URL configured in Azure.

Azure uses this pairing and matching of redirect_uri with Reply URL’s as a security measure to prevent misuse of your application such that, some one could attempt to authenticate their own application using your Azure applications coordinates, and have the access token sent to their application instead of yours.

Once they have an access token, they can use it for whatever purpose and without your knowledge.

So what happens when we try to do this? lets create another authorization URL using a redirect_uri parameter that is not configured as a valid Reply URL in my Azure application…

https://login.microsoftonline.com/1c3d2eea-12db-2ec3-437e-2eec7289e1a1/oauth2/authorize
?client_id=ef92a29b-b332-9d43-1341-23326315fa42
&response_type=id_token+token
&redirect_uri=https%3a%2f%2fpdogs-babel.azurewebsites.net%2Fcallback.html
&state=12345
&nonce=678910
&resource=https%3A%2F%2Fgraph.microsoft.com%2F

Here I’ve set the redirect_uri parameter to https://pdogs-babel.azurewebsites.net, and when I send this to the authorization endpoint…

We see the following error message…

AADSTS50011: The reply address https://pdogs-babel.azurewebsites.net/callback.html does not match the reply addresses configured for the application: ef92a29b-b332-9d43-1341-23326315fa42.

So this is great, Azure is helping us maintain the security of our application, but, one thing you may be tempted to do, is to also add the URL of your local dev server that you use for developing your application, so you end up with Reply URL’s configured as follows…

If you are using the implicit grant flow, this could allow someone to gain an access token using your application coordinates. The initial authorization URL is sent over HTTP by the browser, and the authorisation endpoint returns the reply using a HTTP 302 [Found] response with a Location header value containing the URL found in the redirect_uri parameter plus the hash fragment containing the access_token, as you can see below…

As long as you have a local server listening at (in this case) localhost on port 3000 the browser will dutifully load the URL found in the Location header and Johnny Hacker now has an access_token for your application to do with as they please – all without your knowledge, and when that token expires, they can do the same thing again.

Источник