2016-09-13 11 views
2

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

Скажем, у нас есть коллекция ресурсов под названием things, адресуемая thing ID, напр. things/1, things/44 и т.д.

В настоящее время, когда кто-то запрос маркер доступа с областью things, мы включаем список всех прав, которые пользователь имеет к каждому из things он имеет право:

{ 
    "sub": "Romeo", 
    "scope": [ "things" ], 
    "things": { 
    "1": [ "read", "write", "delete" ], 
    "44": [ "read", "write"], 
    } 
    // ... 
} 

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

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

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

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

+0

Вы нашли решение этой проблемы? – smokedice

ответ

4

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

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

+0

Да, но это может победить использование токенов-носителей? Идея состоит в том, что клиент не должен вообще разговаривать с нашим сервером ресурсов. – romeovs

+0

Вы смешиваете канал с JWT и RS с AS –

+0

Не могли бы вы объяснить мне, что означают RS и AS? Вы говорите, что нет никакого использования для accessTokens, которые содержат права доступа, которые имеет сам токен? – romeovs

1

Я думаю, что @ hans-z имеет это правильно. oAuth не решает эту проблему для вас.

Когда вы попали боль барьер, я хотел бы предложить ваш реализовать User-Service где «вещи» может быть запрошена с маркером JWT.

Чтобы отложить болевой барьер, вы можете подумать об изменении на JSON Web Tokens или на другой реализации, где поддерживается токеновое сжатие или перекодирование токенов с protobuf при отправке по сети.

 Смежные вопросы

  • Нет связанных вопросов^_^