Говоря о SAML, OAuth, OpenID и SSO, JWT и Session

задняя часть сервер алгоритм браузер

предисловие

Обычно, чтобы понять концепцию, нам нужно усвоить десять понятий. в сужденииJWT(JsonWebToken)Можно ли заменитьsessionПрежде чем управлять, мы должны понять, чтоtoken,а такжеaccess tokenиrefresh tokenразница.

понять что такоеOAuth,чтоSSO,SSOразные стратегииOAuthиSAMLразница, иOAuthиOpenIDотличие, а главное, отличиеauthorisationиauthentication.

Наконец мы выводимJSON WEB TOKEN, чатJWT существуетSessionУправляйте сильными и слабыми сторонами и одновременно попытайтесь устранить эти недостатки и посмотрите, каковы затраты и издержки.

текст

Эта статья оOAuth РазрешитьиAPIВызов экземпляров все изGoogle API.

О токене

TokenДаже в компьютерной сфере есть разные определения, здесь мы говоримtoken,Относится кдоступ к ресурсамреквизиты для входа. Например, когда вы звонитеGoogle API, вам необходимо предъявить действительныйtokenчтобы указать, что вы запросилизаконность. этоTokenдаGoogleдля вас это представляетGoogleдля тебяРазрешитьпозволяет вам получить доступAPIПозадиресурс.

проситьAPIпри переноскеtokenЕсть также много способов, черезHTTP Headerилиurlпараметр илиgoogleПредоставленная библиотека классов может:

  • HTTP Header
GET /drive/v2/files HTTP/1.1

Authorization: Bearer <token>
Host: www.googleapis.com/
  • URL-параметры
GET https://www.googleapis.com/drive/v2/files?token=<token>
  • Библиотека функций Python
from googleapiclient.discovery import build
drive = build('drive', 'v2', credentials=credentials)

В частности, приведенное выше используется для вызоваAPIизtoken, которые мы называем разделенными наaccess token. как правилоaccess tokenТам естьСрок годности, еслиИстекшийнужноПолучить. Так как же вернуть? Взгляните на первое приобретениеtokenКак выглядит процесс:

  1. Сначала нужноGoogle APIПодпишитесь на приложение, и вы получите его после регистрацииИнформация о сертификации(credentials)включаютIDиsecret. Не все типы программ имеютsecret.

  2. следующий заGoogleпроситьaccess token. Не обращайте внимания на некоторые детали здесь, такие как параметры запроса (конечно, вам нужно подать заявку на вышеsecret). Важно, если то, к чему вы хотите получить доступ,Пользовательские ресурсы, пользователю будет напомненоРазрешить.

  3. еслиАвторизация пользователяполный.Googleвернусьaccess token. или вернутьсяКод авторизации(authorization code), а затем получить кодaccess token.

tokenПосле того, как вы его получите, вы можете взять его с собойtokenдоступAPI.

Процесс показан на рисунке ниже:

Примечание: Пройдено на третьем шагеauthorization codeобменaccess tokenв процессе,Googleне просто возвращаетсяaccess token, также вернет дополнительную информацию, связанную с последующими обновлениями.refresh token.

однаждыaccess tokenистек срок, вы можете пройтиrefresh tokenзапросить сноваaccess token.

Вышеупомянутое является лишь грубым изложением, и некоторые дополнительные понятия намеренно опущены. например, обновлениеaccess tokenКонечно, вам не нужноrefresh token, это зависит от вашегометод запросаи доступныйТип ресурсаЗависит от.

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

  1. еслиrefesh tokenА если он еще и просрочен? В это время пользователям необходимоПовторная авторизация.

  2. Зачем различатьrefresh tokenиaccess token? Если объединить в одинtokenтогда поставьДата истечения срока годностискорректированныйдольше, и каждый разнедействителенпользователь послеПовторная авторизацияДостаточно? Этот вопрос будет связан с соответствующими понятиями, обсуждаемыми позже, которые будут объяснены позже.

OAuth 2.0

Получить отtokenиспользоватьtokenинтерфейс доступа. Это на самом деле стандартOAuth2.0доступ под механизмAPIпроцесс. Вот введениеOAuthВнутренние и внешние связанные концепции, более глубокое пониманиеtokenэффект.

SSO (Single sign-on)

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

SSOэто классрешениеЧто касается конкретной реализации, у нас есть две стратегии на выбор:

  • SAML 2.0

  • OAuth 2.0

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

Authentication VS Authorisation

  • Authentication:Идентификация, именуемая в дальнейшемСертификация;

  • Authorisation:доступ к ресурсамРазрешить.

Сертификациярольпризнанныйвы можете получить доступ к системе дляАутентификация посетителейтак или иначезаконный пользователь;иРазрешитьиспользуется, чтобы решить, что у вас есть доступкакие ресурсы имеют разрешения.

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

Authorization Server/Identity Provider(IdP)

поставить во главесертифицированный сервисназываетсяAuthorizationServerилиIdentityProvider, именуемый в дальнейшемIDP.

Service Provider(SP)/Resource Server

поставить во главепредоставить ресурсы(APIвызов) служба вызываетсяResourceServerилиServiceProvider, именуемый в дальнейшемSP.

SAML 2.0

На картинке нижеSAML2.0Блок-схема, посмотрите на картинку, чтобы говорить:

  1. Такжене вошелПользовательОткрыть браузерзайти на ваш сайт(SP),Веб-сайтПредоставлять услугино нетНе несет ответственности за аутентификацию пользователей.

  2. тогдаSPВ направленииIDPотправилSAMLзапрос аутентификации, в то время какSPбудетПользовательский браузерперенаправить наIDP.

  3. IDPПосле проверки отSPизЗапрос правильныйПосле этого рендерить в браузереформа входаПозвольте пользователю заполнитьимя пользователяипарольчтобы залогиниться.

  4. После того, как пользователь успешно войдет в систему,IDPбудет генерировать содержащийИнформация о пользователе(имя пользователяилипароль)изSAML token(SAML tokenТакже известен какSAML Assertion,По сутиXMLузел).IDPВ направленииSPвозвращениеtoken, и воляПеренаправление пользователяприбытьSP (tokenВозврат вШаги перенаправления, о чем будет подробно рассказано ниже).

  5. SPправильно получилtokenПодтвердить и проанализировать егоИнформация о пользователе,Напримеркто пользовательа такжеразрешения пользователяЧто. На основании этой информации пользователям может быть разрешен доступ к содержимому нашего веб-сайта.

когда пользовательIDPПосле успешного входа,IDPпользователь долженперенаправить сноваприбытьSPсайт, обычно есть два способа сделать этот шаг:

  • HTTPПеренаправление: это не рекомендуется, потому чтоперенаправитьизURLдлинаограниченное, не может нести более длинную информацию, такую ​​какSAML Token.

  • HTTP POSTЗапрос: это более традиционный подход.После того, как пользователь входит в систему, отображается форма, и пользователь нажимаетSPОтправитьPOSTпросить. В качестве альтернативы вы можете использоватьJavaScriptВ направленииSPвыпуститьPOSTпросить.

Если ваше приложение основано наWeb, то с вышеописанной схемой проблем нет. Но если вы разработаетеiOSилиAndroid, то возникает проблема:

  1. пользователь вiPhoneоткрыть приложение наIDPАутентифицировать.

  2. приложение перейти кSafariБраузер, после завершения аутентификации входа, должен пройтиHTTP POSTбудет в видеtokenвернуться кмобильное приложение.

Несмотря на то чтоPOSTизurlМожетоткрыть приложение,номобильное приложениене удалось разобратьPOST, мы не сможем прочитатьSAML Token.

Конечно, есть способы, напримерIDP этап авторизациине лезь в системуSafariбраузер, вв линиюизWebviewв решении, пытаясь найти способы получить отWebviewизвлечь изtokenили используйтепрокси-сервер.

так или иначе,SAML 2.0иНепригодныйв настоящее времяКроссплатформенностьсцена, которая также может иметь какое-то отношение к возрасту2005лет, в тот моментHTTP POSTЭто действительно лучший вариант.

OAuth 2.0

Давайте кратко разберемсяSSOвнизOAuth2.0процесс.

  1. пользователь черезклиент(возможнобраузертак же может бытьмобильное приложение) хотите получить доступSPресурсы на , ноSPскажите пользователю, чтоСертификация, ПользовательперенаправитькIDP.

  2. IDPВ направленииПользовательпроситьSPМожно ли получить доступИнформация о пользователе. Если пользователь согласен,IDPВ направленииклиентвозвращениеauthorization code.

  3. Клиент получаетauthorization codeВ направленииIDPобменaccess token, и возьмиaccess tokenВ направленииSPЗапросить ресурсы.

  4. SPПосле принятия запроса возьмите прикрепленныйtokenВ направленииIDPпроверятьличность пользователя. Убедившись, что личность верна,SPВ направленииклиентРаспространяйте соответствующие ресурсы.

ТакOAuthкак избежатьSAMLв процессене удалось разобрать POSTЧто можно сказать о содержании информации?

  • С одной стороны, пользовательIDPвозвращениеклиентпути, также черезURLперенаправить сюдаURLпозволятьнастроить schema, так что даже еслимобильный телефонтакже можетоткрыть приложение;

  • С другой стороны, потому чтоIDPВ направленииклиентпрошлоauthorization code, вместоXMLинформация, поэтомуcodeможно легко прикрепить кперенаправить URLпередача дальше.

но вышеSSOПроцесс не отражаетOAuthнамерение.OAuthнамерениеприложениепозволятьдругое приложениесуществуетАвторизация пользователяв случаеполучить доступ к своим данным.

OAuthДизайнерский замысел более склонен кАвторизация вместо аутентификации(Конечно, авторизация пользовательской информации косвенно обеспечивает аутентификацию), хотяGoogleизOAuth 2.0 APIТакже поддерживаетРазрешитьиСертификация. Итак, вы используетеFacebookилиGmailКогда учетная запись входит на сторонний сайт, она появитсяДиалог авторизации,Сказать тебесторонний сайтДоступ к вашей информации требует вашего согласия.

наверхуSSOизOAuthВ процессе задействованы три роли:SP, IDPа такжеClient. но на практикеClientможет не существовать, например, вы пишетесерверная программатайм-пассGoogle APIотYoutubeИзвлеките последние данные программы, затемсерверная программанужно получитьYoutubeизOAuth РазрешитьВот и все.

OAuth VS OpenId

Если вы обратите внимание, вы увидите на некоторых сайтах, чтоOpenIDспособ войти в систему, на самом деле, заключается в использованииFacebookсчет илиGoogleСайт входа в аккаунт:

OpenIDиOAuthТак же, как. Но по сути это две совершенно разные вещи:

  • OpenID:только дляАутентификация(Authentication), что позволяет использоватьтот же аккаунтсуществуетВход на несколько веб-сайтов. это только для тебяюридическое лицоодобрение, когда вы начинаете сFacebookПосле входа учетной записи на сайт сайтнет доступаты вFacebookВверхданные.

  • OAuth:используется дляРазрешить(Authorisation),позволятьуполномоченная сторонадоступуполномоченная сторонаизДанные пользователя.

Refresh Token

Теперь, чтобы ответить на поставленный выше вопрос, зачем нам нужноrefresh token?

Такая обработка предназначена дляразделение обязанностей:

  • refresh token:ответственныйАутентификация;

  • access token:ответственныйзапросить ресурс.

Несмотря на то чтоrefresh tokenиaccess tokenвсе поIDPвыпущено, ноaccess tokenтакже сSPпровестиобмен данными,еслипубличные словаТам будетутечка личных данныхвозможный. иIDPиSPможет бытьполностью отличаетсяизпредоставление услугиз. В вышеизложенном причина, по которой у нас нет таких опасений, заключается в том, чтоIDPиSPобаGoogle.

JWT

Предварительное понимание

По сутиJWTСлишкомtoken, как мы уже упоминали выше, этодоступ к ресурсамизсертификат.

GoogleНекоторые изAPIТакие какPrediction APIилиGoogle Cloud Storage, не требуетсядоступпользователиличные данныеиз. так что не надо проходитьАвторизация пользователяНа этом шаге приложение может получить прямой доступ. как вышеOAuthНет вClientПроцесс без участия аналогичен. это использоватьJWTПосле завершения визита конкретный процесс выглядит следующим образом:

  1. Сначала вам нужноGoogle APIСоздайте учетную запись службы на (service account).

  2. Получатьсервисный аккаунтизИнформация о сертификации(credential),включаютадрес электронной почты,client ID, и параоткрытый/закрытый ключ.

  3. использоватьClient IDизакрытый ключСоздайподписатьизJWT, затем поместите этоJWTОтправитьGoogleобменaccess token.

  4. Googleвозвращениеaccess token.

  5. программа прошлаaccess tokenдоступAPI.

Вам даже не нужноGoogleспроситьaccess token, но нестиJWTв видеHTTP headerвнутреннийbearer tokenпрямое интервьюAPIэто тоже хорошо. этоJWTвеличайшее очарование.

рациональное знание

JWTКак следует из названия, этоJSONструктурныйtoken, состоит из трех частей:

  • header

  • payload

  • signature

header

headerиспользуется для описанияметаинформация, например, для производстваsignatureАлгоритм:

{    
    "typ": "JWT",
    "alg": "HS256"
}

вalgКлючевое слово указывает, какой из них использоватьхеш-алгоритмсоздаватьsignature.

payload

payloadдля выполнения вашего желанияпройти на серверИнформация. Вы можете либо добавитьофициальное поле,Например:iss(Issuer), sub(Subject), exp(Expirationtime), также можно подключитьНастраиваемые поля,НапримерuserId:

{
    "userId": "b08f86af-35da-48f2-8fab-cef3904660bd"
}

signature

signatureперевести какподписать, для создания подписи необходимо выполнить следующие шаги:

  1. отсервер интерфейсаполучитьключ, при условии, чтоsecret.

  2. правильноheaderпровестиbase64кодирование, предполагая, что результатheaderStr.

  3. будетpayloadпровестиbase64кодирование, предполагая, что результатpayloadStr.

  4. будетheaderStrиpayloadStrиспользовать. персонажсобраны в символыdata.

  5. отdataиsecretВ качестве параметра используйтехеш-алгоритмРассчитатьподписать.

Если приведенное выше описание не интуитивно понятно, используйтеПоддельный кодЭто значит:

// Signature algorithm
data = base64urlEncode( header ) + “.” + base64urlEncode( payload )
signature = Hash( data, secret );

Предположим, наш оригиналJSONСтруктура такая:

// Header
{
    "typ": "JWT",
    "alg": "HS256"
}

// Payload
{
    "userId": "b08f86af-35da-48f2-8fab-cef3904660bd"
}

еслиключэто строкаsecretзатем в конце концовJWTРезультат таков:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

допустимыйjwt.ioначальствопроверятьэтот результат.

Что именно дает JWT

обеспечить целостность данных

JWTцель не в томСпрятатьиликонфиденциальные данные, но чтобы убедиться, чтоданныедействительно изавторизованная личностьсоздан для предотвращенияФальсификация на полпути.

Вспомните, когда вы получилиJWTкогда можно обойтись безsecretрасшифровывается в случаеheaderиpayload,так какheaderиpayloadтолько что прошелbase64кодирование(encode), целью кодирования являетсяОблегчение передачи структур данных.

Хотя созданиеsignatureПроцесс примерношифрование (encrypt), но суть на самом делеподписать (sign) поведение, для гарантиицелостность данных, на самом деле и такжеДанные не зашифрованы.

для интерфейсных вызовов

следующий вAPIможно прикрепить к звонкуJWT(обычно вHTTP Headerсередина). Также из-заSPвстреча и программаобщийОдинsecret,такпрограммав состоянии пройтиheaderпри условии того жеhashалгоритм дляПодтвердить подписьПравильно ли, чтобы определить, имеет ли приложение право вызыватьAPI.

Сеанс разговора с отслеживанием состояния

так какHTTPданет статуса, такклиентиСерверПроблема, которую необходимо решить, заключается в том, как сделать диалог между ними с сохранением состояния. Только для примерастатус входаизПользовательиметь разрешение только на вызов определенных интерфейсов, то вЛогин пользователяПосле этого нужно помнить, что пользовательзалогинилсястатус. Распространенный подход заключается в использованииsessionмеханизм.

ОбщийsessionМодель работает так:

  1. пользователь в браузереавторизоватьсяПосле этого сервер генерирует для пользователяТолькоизsession id, сохранить вСерверизслужба хранения(НапримерMySQL, Redis)середина.

  2. Долженsession idТакже в то же времявернуться в браузер,отSESSION_IDзаKEYхранится в браузереcookieсередина.

  3. Если пользователь снова посещает сайт,cookieвнутреннийSESSION_IDпоследуетпроситьотправить вместеСервер.

  4. Сервер судитSESSION_IDЭто уже вRedisопределить, находится ли пользователь встатус входа.

Я полагаю, вы заметили, теоретически говоря,JWTмеханизм может заменитьsessionмеханизм. Пользователю не нужно входить в систему заранее, равно как и серверная частьRedisЗапишите данные для входа пользователя. Местный клиент сохранить юридическийJWT, когда пользователю нужно вызвать интерфейс, прикрепите юридическийJWT, каждый раз, когда вызывается интерфейс, серверная часть используетJWTсделать один разПроверка легитимности. Это также косвенно достигаетсяАвторизованный пользовательцель.

тем не мениеJWTдействительно заменитьsessionмеханизм? Каковы преимущества и недостатки этого? Эти вопросы будут рассмотрены в следующей статье.

Добро пожаловать в технический публичный аккаунт: Zero One Technology Stack

零壹技术栈

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

Категории