2015-07-20 4 views
1

После получения действительного токена доступа считается, что наилучшей практикой является вызов вызова конечной точке userinfo и получение метаданных пользователя для каждого последующего вызова в ваше приложение или если вместо этого следует позвонить userinfo вызываться один раз, и ответ метаданных пользователя, хранящийся в, например, в cookie, так что последующие запросы считывают метаданные пользователя из файла cookie, а не вызывают вызов userinfo для каждого запроса.OpenID Connect UserInfo Конечная точка использования

ответ

1

В конце концов, это зависит от случая использования:

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

Но ваш клиент может даже не зависеть от данных, которые меняются, например. если единственное, что он использует, это постоянный идентификатор (sub) и given_name/family_name. Тогда даже если есть другие данные, возвращаемые с конечной точки информации пользователя, которые могут со временем меняться, ваш клиент не будет беспокоиться и скорее кэшировать sub, given_name и family_name, не вызывая снова конечную точку информации пользователя.

Кроме того, претензии могут быть возвращены в рамках id_token (например, вкл. first_namefamily_name), который может быть достаточно для некоторых случаев применения, так что нет необходимости для вызова информации о пользователе конечной точки на всех.

В целом: это зависит от типа информации, возвращаемой с конечной точки информации пользователя, требований клиента к информации и информации, уже доступной в id_token.