Единый вход с помощью OAuth2: сохранение маркера обновления в файлах cookie

Мне нужно реализовать сервер централизованной аутентификации с единой регистрацией.

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

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

Чтобы было понятно, далее я опишу, как я представляю поток OAuth2 и SSO для совместной работы:

1. Пользователь вводит свои учетные данные и отправляет форму авторизации в сервис-провайдере
2. Поставщик услуг (SP) отправляет запрос поставщику удостоверений (IdP), чтобы проверить, действительны ли учетные данные (Запрос подписан с идентификатором клиента и секретным ключом в качестве маркера носителя base64: base64(client_id:secret))
3. Если учетные данные действительны, IdP создает токен доступа (5 минут) и обновляет токен (24 часа) и возвращает их в SP
4. При каждом запросе пользователя SP использует токен доступа для получения пользовательских данных от IdP.
5. Если срок действия токена истек, SP делает еще один запрос с токеном обновления для получения нового токена доступа. Запрос должен быть подписан с идентификатором клиента и секретом.

Так что в значительной степени, как будет работать предоставление пароля OAuth2, вероятно, самая сложная часть — заставить его работать с SSO, я не мог найти какие-либо работающие реализации без сохранения состояния, поэтому придумал это:

1. Когда выдаются токены доступа и обновления, IdP сохраняет токен обновления в файле cookie.
2. Когда пользователь впервые посещает SP, выполняется быстрая переадресация на IdP, если токен обновления существует в файле cookie, он добавляется в качестве параметра запроса к URL-адресу перенаправления, и пользователь перенаправляется обратно в SP. Если нет, то добавляется некоторый параметр запроса, чтобы определить, что пользователь не вошел в систему, чтобы избежать цикла перенаправления.
3. SP использует полученный токен обновления для выдачи нового токена доступа (который уникален для каждого SP).

Таким образом, токен доступа может использоваться только поставщиком услуг, для которого он был выдан. И токен обновления может использоваться всеми поставщиками услуг, но для выдачи нового токена доступа должны быть указаны идентификатор клиента и секрет, поэтому один токен обновления бесполезен.

Также забыл упомянуть, что все сайты используют TLS.

Что вы думаете об этой реализации, достаточно ли она безопасна? Может быть, у вас есть другие предложения?