spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

For example, a malicious relying party may forward the end-user to a bogus identity provider authentication page asking that end-user to input their credentials. On completion of this, the malicious party (who in this case also control the bogus authentication page) could then have access to the end-user's account with the identity provider, and as such then use that end-user’s OpenID to log into other services.

Zitat

If the user accepts the identity provider's request to trust the relying party web site, the browser is redirected to the designated return page on the relying party web site along with the user's credentials. That relying party must then confirm that the credentials really came from the identity provider. If they had previously established a shared secret (see above), the relying party can validate the shared secret received with the credentials against the one previously stored. Such a relying party is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb relying party must make one more background request (check_authentication) to ensure that the data indeed came from the identity provider.

After the OpenID identifier has been verified, OpenID authentication is considered successful and the user is considered logged in to the relying party web site with the given identifier (e.g. alice.openid.example.org). The web site typically then stores the OpenID identifier in the user's session.