Salesforce Developer Security Auth Openid Oauth2
// Salesforce - Developer - Security - OpenID - Why Not Just Use OAuth 2.0: You might be asking yourself why we need OpenID Connect at all - after all, OAuth 2.0 provides an access token, which a client app can use to retrieve user information, effectively discovering the identity of the user to whom the token was issued. Why do we need an additional layer of protocol? The answer is that OAuth 2.0 allows the user to authorize the client app to access resources such as APIs on the user's behalf; the access token is a 'bearer' token allowing the app to make API calls. What happens if we do use the access token to represent the user's identity? Let's say your account is at ProviderCo, and you are using GoodApp, a mobile app that gives access to some cool functionality on the GoodApp servers. GoodApp uses OAuth 2.0 to obtain an access token from ProviderCo to retrieve your user profile, including attributes such as your name and email address, and (crucially) gives you access to resources based on the fact that it receives that access token. Now let's imagine that an attacker wants to access your resources at GoodApp. The attacker can make his own app, BadApp. The app itself is completely innocuous - a game, perhaps. The attacker registers BadApp with ProviderCo so that BadApp also receives access tokens to retrieve user profiles. Here is the problem with using those access tokens to represent authentication: OAuth 2.0 is designed to give apps access to resources; nothing more. Once BadApp has an access token, properly issued to it for the purpose of obtaining the user profile, it can engineer an interaction with GoodApp where it appears to be both the user and ProviderCo, presenting its access token and gaining access to the user's resources at GoodApp. GoodApp has no way of knowing that the token was issued to BadApp - all it sees is a token that gives access to a user profile.
page revision: 0, last edited: 01 Jan 2017 23:25