Исправление bryak, (текущая версия) :
Общее положение: auth имеет riv key, с помощью которого выдает refresh_token и access token. Он же занимается перевыдачей refresh_token и access token. Profile занимается регистрацией пользователей по username(phone), user_password.
Реализацию можно разделить на два подхода:
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token локально без обращения к auth. И этого хотелось бы добиться в итоге(и возможно ли это?)
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token, внутри которого есть некий идентификатор, который является индикатором того, что access_token выдан валидным на текущий момент refresh_token. При расшифровке access_token profile стучится в auth, где сохранен этот идентификатор, смотрит, если идентификатор валидный - значит этот access_token валидный
По первому пункту всё ясно(если учесть, что profile не стучится в auth за валидацией access_token). И я не думаю, что можно как-то технически реализовать валидацию access_token
По второму пункту - всё сложней. Мне и сейчас в полном объеме не ясно как происходит перевыдача refresh_token(потому что его могли украсть). Вообще, если взять и начать отвечать на этот вопрос не текстом, а формированием полей внутри токенов, то сразу появляется много вводных, которые нужно обрабатывать
PS:Я лично считаю, что невозможно перевыпускать refresh_token без какой-то идентификации клиента(т.е пароля или фингерпринта отпечатка пальца(или что там используется))
PPSS: на текущий момент времени нет готового решения для того, чтобы решить вопрос централизованной безопасной token авторизации в djangorest
Исправление bryak, :
Общее положение: auth имеет riv key, с помощью которого выдает refresh_token и access token. Он же занимается перевыдачей refresh_token и access token. Profile занимается регистрацией пользователей по username(phone), user_password.
Реализацию можно разделить на два подхода:
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token локально без обращения к auth. И этого хотелось бы добиться в итоге(и возможно ли это?)
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token, внутри которого есть некий идентификатор, который является индикатором того, что access_token выдан валидным на текущий момент refresh_token. При расшифровке access_token profile стучится в auth, где сохранен этот идентификатор, смотрит, если идентификатор валидный - значит этот access_token валидный
По первому пункту всё ясно(если учесть, что profile не стучится в auth за валидацией access_token). И я не думаю, что можно как-то технически реализовать валидацию access_token
По второму пункту - всё сложней. Мне и сейчас в полном объеме не ясно как происходит перевыдача refresh_token(потому что его могли украсть). Вообще, если взять и начать отвечать на этот вопрос не текстом, а формированием полей внутри токенов, то сразу появляется много вводных, которые нужно обрабатывать
PS:Я лично считаю, что невозможно перевыпускать refresh_token без какой-то идентификации клиента(т.е пароля или фингерпринта отпечатка пальца(или что там используется))
PPSS: на текущий момент времени нет готового решения для того, чтобы решить вопрос централизованной token авторизации в djangorest
Исправление bryak, :
Общее положение: auth имеет riv key, с помощью которого выдает refresh_token и access token. Он же занимается перевыдачей refresh_token и access token. Profile занимается регистрацией пользователей по username(phone), user_password.
Реализацию можно разделить на два подхода:
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token локально без обращения к auth. И этого хотелось бы добиться в итоге(и возможно ли это?)
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token, внутри которого есть некий идентификатор, который является индикатором того, что access_token выдан валидным на текущий момент refresh_token. При расшифровке access_token profile стучится в auth, где сохранен этот идентификатор, смотрит, если идентификатор валидный - значит этот access_token валидный
По первому пункту всё ясно(если учесть, что profile не стучится в auth за валидацией access_token). И я не думаю, что можно как-то технически реализовать валидацию access_token
По второму пункту - всё сложней. Мне и сейчас в полном объеме не ясно как происходит перевыдача refresh_token(потому что его могли украсть). Вообще, если взять и начать отвечать на этот вопрос не текстом, а формированием полей внутри токенов, то сразу появляется много вводных, которые нужно обрабатывать
Я лично считаю, что невозможно перевыпускать refresh_token без какой-то идентификации клиента(т.е пароля или фингерпринта отпечатка пальца(или что там используется))
Исправление bryak, :
Общее положение: auth имеет riv key, с помощью которого выдает refresh_token и access token. Он же занимается перевыдачей refresh_token и access token. Profile занимается регистрацией пользователей по username(phone), user_password.
Реализацию можно разделить на два подхода:
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token локально без обращения к auth. И этого хотелось бы добиться в итоге(и возможно ли это?)
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token, внутри которого есть некий идентификатор, который является индикатором того, что access_token выдан валидным на текущий момент refresh_token. При расшифровке access_token profile стучится в auth, где сохранен этот идентификатор, смотрит, если идентификатор валидный - значит этот access_token валидный
По первому пункту всё ясно(если учесть, что profile не стучится в auth за валидацией access_token). И я не думаю, что можно как-то технически реализовать валидацию access_token
По второму пункту - всё сложней. Мне и сейчас в полном объеме не ясно как происходит перевыдача refresh_token(потому что его могли украсть). Вообще, если взять и начать отвечать на этот вопрос не текстом, а формированием полей внутри токенов, то сразу появляется много вводных, которые нужно обрабатывать
Я лично считаю, что невозможно перевыпускать refresh_token без какой-то идентификации клиента(т.е пароля)
Исходная версия bryak, :
Общее положение: auth имеет riv key, с помощью которого выдает refresh_token и access token. Он же занимается перевыдачей refresh_token и access token. Profile занимается регистрацией пользователей по username(phone), user_password.
Реализацию можно разделить на два подхода:
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token локально без обращения к auth. И этого хотелось бы добиться в итоге(и возможно ли это?)
Auth генерирует refresh_token и access_token . Profile расшифровывает access_token, внутри которого есть некий идентификатор, который является индикатором того, что access_token выдан валидным на текущий момент refresh_token. При расшифровке access_token profile стучится в auth, где сохранен этот идентификатор, смотрит, если идентификатор валидный - значит этот access_token валидный
По первому пункту всё ясно(если учесть, что profile не стучится в auth за валидацией access_token). И я не думаю, что можно как-то технически реализовать валидацию access_token
По второму пункту - всё сложней. Мне и сейчас в полном объеме не ясно как происходит перевыдача refresh_token(потому что его могли украсть). Вообще, если взять и начать отвечать на этот вопрос не текстом, а формированием полей внутри токенов, то сразу появляется много вводных, которые нужно обрабатывать