Ответ 1

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

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

токены JWT

Ленты доступа могут быть непрозрачными строками, которые вы храните на сервере, однако я настоятельно рекомендую использовать токены JWT. Знаки JWT имеют 2 основных преимущества над непрозрачными (бессмысленными) токенами:

1. Требования клиентов

Первое, что вам нужно сделать в пост-авторизации вашего клиентского приложения, - это поиск всех видов материалов для создания пользовательского интерфейса. Красота жетонов JWT заключается в том, что они хранят все ваши требования пользователей (в том числе ваши пользовательские заявки пользователя) в качестве полезной нагрузки объекта JSON внутри закодированной строки, которая может быть декодирована на стороне клиента, сначала разбивая токен на ., который прерывается он в строки [ header, payload, sig ] base 64 закодированные. Затем вы можете создать 64-й декодировать строку полезной нагрузки и запустить ее через JSON.parse, который будет генерировать пары ключевых слов вашей заявки:

const access_token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ'
const claims = JSON.parse(atob(access_token.split('.')[1]))
console.info(claims)

Ответ 2

Я предлагаю вам взглянуть на ответ, который я сделал здесь, на то, что связано с аутентификацией: Метод авторизации для REST API с использованием Active Directory

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

Как только у вас есть сервер аутентификации Oauth (из коробки ADFS, custom thinktecture в .net, пользовательский oauth2orize в nodeJs), вы можете подключить к нему что угодно, как к стандарту протокола аутентификации. Например, у Xamarin есть что сделать для аутентификации с любым сервером oauth2: https://components.xamarin.com/gettingstarted/xamarin.auth. И, как я упоминал в предыдущем ответе, любая технология веб-сервера или технология javascript имеют что-то для обработки OAuth2.

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

Ответ 3

Да, это то, что я делаю для своих проектов сейчас. И это общий шаблон.

Архитектура приложения:

[Web Applications]     <-HTTPS/TLS-> [Restful Web API]

[PC Applications]      <-HTTPS/TLS-> [Restful Web API]

[Mobile Applications]  <-HTTPS/TLS-> [Restful Web API]
                                     [Restful Web API] <-Authenticate-> [over LDAP or SQL Database]
                                     [Restful Web API] <-File Stream-> [File system/file server]

ПРИМЕЧАНИЯ:

На ваш дизайн будут влиять некоторые примечания:

• Управление временем жизни токена.

  • Убедитесь, что ваш токен имеет короткую истекшую дату (должно быть через 30 минут или меньше). Если токен истек (или истекает), то вы должны обновить свой токен (более подробно посмотрите refresh token в OAUTH2).
  • Удостоверьтесь, что ваш маркер будет отброшен после выхода из системы.
  • Если конечный пользователь сообщает, что кто-то использует свою учетную запись без их разрешения. Убедитесь, что вы можете завершить токен вора. (Это важно в корпоративном приложении)

• Защитите свой токен

  • Избегайте сохранения вашего токена в cookie. Используйте локальное хранилище, если сможете.
  • Используйте HTTPS вместо HTTP.
  • Каждая платформа должна использовать выделенный токен: это поможет. Если вы планируете публиковать свой API другому разработчику/платформе/поставщику.
  • Удостоверьтесь, что вы заносили в журнал все ваши выпущенные истории токенов (когда и выдается кем). Представьте, что ваше приложение находится под атакой, вы не знаете, откуда появился токен. Это поможет вам ответить: Were your private key stolen by attacker?!

• Защитите свой статический ресурс (*.pdf, images, *.doc,...)

  • Вы не можете защитить свой статический ресурс обычным способом (отправляя HTTP-заголовок авторизации). Затем вы должны отправить его через Cookie (которого я не поощряю). Таким образом, вы должны создать защищенный токен для статического ресурса, этот токен должен быть жив через 5 минут или меньше

Ответ 4

Да, это с особым отклонением от того, что вы описали. Читайте о OAuth2 танец аутентификации, так как это может включать стороннего пользователя для аутентификации клиента (desktop/web/native mobile) с сервером приложений.

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

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

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

Ответ 5

@cchamberlain уже ответил, но... вы можете ссылаться [здесь] (метод авторизации для REST API с использованием Active Directory), я думаю, это поможет вам решить вашу проблему,

Спасибо!