> Итак, вы предлагаете, не хранить access token'ы в БД Authorization Server'а,
> только refresh токены. Значит придется их хранить в памяти — хозяин барин.
Как я понимаю, если токен — не случайное число, а криптографический токен, то для проверки его подлинности не нужно использовать БД и где либо вообще его хранить.
Если требуется реализовать механизм отзыва, то храниться/распространяться должны токены из черного списка, а не рабочие токены. Отзыв токена — гораздо более редкая ситуация (плохих токенов много меньше, чем рабочих), плюс к этому, срок жизни access-токена сильно ограничен.
> Случай 1: Боб узнал оба токена Алисы и не воспользовался refresh
> Случай 2: Боб узнал оба токена Алисы и воспользовался refresh
Вопрос: а в случае только одного токена разве не тоже самое можно сделать?
Копирую почти один-в-один, только с одним токеном:
Случай 1: Боб узнал токен Алисы и не воспользовался refresh
В этом случае Боб получит доступ к сервису на время жизни token. Как только оно истечет и приложение, которым пользуется Алиса, воспользуется token, сервер вернет новый токен, а тот, что узнал Боб, превратится в тыкву.
Случай 2: Боб узнал токен Алисы и воспользовался refresh
В этом случае токен Алисы превращается в тыкву, приложение предлагает ей авторизоваться логином и паролем, сервер возвращает новый токен, а тот, что узнал Боб, снова превратится в тыкву (тут есть нюанс с device id, может вернуть тот же что и у Боба. В таком случае следующее использование токена превратит токен Боба в то, что изображено справа).
Помидоры есть и самоопыляющиеся, не в этом суть. Для помидоров, перцев и т.д. нужно много грунта, дренаж. Думаю, требуемый объем грунта просто не взлетит.
> только refresh токены. Значит придется их хранить в памяти — хозяин барин.
Как я понимаю, если токен — не случайное число, а криптографический токен, то для проверки его подлинности не нужно использовать БД и где либо вообще его хранить.
Если требуется реализовать механизм отзыва, то храниться/распространяться должны токены из черного списка, а не рабочие токены. Отзыв токена — гораздо более редкая ситуация (плохих токенов много меньше, чем рабочих), плюс к этому, срок жизни access-токена сильно ограничен.
> Случай 2: Боб узнал оба токена Алисы и воспользовался refresh
Вопрос: а в случае только одного токена разве не тоже самое можно сделать?
Копирую почти один-в-один, только с одним токеном:
Случай 1: Боб узнал токен Алисы и не воспользовался refresh
В этом случае Боб получит доступ к сервису на время жизни token. Как только оно истечет и приложение, которым пользуется Алиса, воспользуется token, сервер вернет новый токен, а тот, что узнал Боб, превратится в тыкву.
Случай 2: Боб узнал токен Алисы и воспользовался refresh
В этом случае токен Алисы превращается в тыкву, приложение предлагает ей авторизоваться логином и паролем, сервер возвращает новый токен, а тот, что узнал Боб, снова превратится в тыкву (тут есть нюанс с device id, может вернуть тот же что и у Боба. В таком случае следующее использование токена превратит токен Боба в то, что изображено справа).
Ну и зачем тогда пара токенов?
Сомнительное предложение. Повторение тестов может выявить плавающие ошибки.
Датирована 2014 годом, сделана с использованием fixed-form.
Интерфейс функций по современным меркам, мягко говоря, неудобный.
Авторы, конечно, молодцы, постарались сделать максимально удобно, но все равно это остается анахронизмом.
Особенно, в режиме «fixed-form source», в котором длина строки должна быть не больше 72 символов, а символы дальше 72 позиции просто игнорируются.
Сейчас такое может присниться только в самом страшном сне.
The old mali-400 does neither support opencl nor cuda(obvious, since its nvidia only). The gpu only supports opengl ES 2.0
Или эта информация уже не актуальна?
ни какие ASIC не будут нужны, будут сплошные тонкие клиенты.