Overview: With the introduction of Apps into the SharePoint 2013 world, OAuth is an essential mechanism to understand. OAuth is a standard for authorisation of resources, it does not verify a users identity/Authentication. This post explains in simple terms what OAuth is about. The goal of OAuth is to allow Consumers (TweetAppFiction/my custom program) to use resources from a Service Provider (Twitter in this case). For authentication purposes, the web application "TweetAppFiction" will redirect you to sign into Twitter on Twitters site, after you have logged into Twitter successfully, your browser is redirected back to "TweetAppFiction" with a token. The token verifies who you are. This allows your users to login to your site by using there large trusted websites credentials(FaceBook/Google/Yahoo), without them having to provide credentials to your new unknown site.
Tip: Replace TweetAppFiction with an app you are happy to consider as your consumer/app. Examples of apps/consumer apps are TweetDeck and TweetApp.
Problem: So how OAuth shouldn't work: The end users signup with TweetAppFiction, TweetAppFiction asking the user for their Twitter, LinkedIn, Email etc. username and password. TweetAppFiction now can work on your behalf with Twitter and the other Service Providers you have given. The problem is you have given TweetAppFiction your full access credentials. You don't know or trust "TweetAppFiction". TweetAppFiction can now do any action it wishes against your Twitter account. Another issue is if TweetAppFiction gets hacked, your Twitter credentials are compromised.
OAuth/OpenId stops the end-users creating another set of credentials by allowing the Service Provider e.g. Twitter for another website. The end-user is directed to the Service Provider (twitter) where they authenticate themselves and tell the Service Provider (twitter) to allow this new web application to verify who they are (it also can give other permissions; in effect roles/services).
The issues OAuth solves for end-users are:
Authorisation: This is the setup of allowing the consumer (TweetAppFiction) to use a Service Provider (Twitter) on your behalf to verify end users.
The end-user on the TweetAppFiction website/mobile app is going to create an account that logs you in using Twitter. TweetAppFiction will send your browser a URL that allows you to go to Twitter, and give TweetAppFiction permissions. If you are not already logged into Twitter you are prompted for your Twitter credentials. Once you grant the permissions, Twitter sends TweetAppFiction a token (this in effect is a set of credentials and roles for TweetAppFiction to use that is not your username and password but has a limited set of functionality it can perform on your behalf). Note: TweetAppFiction had to do an initial trust setup with Twitter that involves a Consumer Key & Consumer Secret (Think of this as the original trust relationship setup where Twitter is accepting TweetAppFiction to access TwittersOAuth API)/Resouce Server). OpenId does not need to perform this initial connection step (Google and Yahoo use OpenId).
Trusted Usage: For example, TweetAppFiction provides the ability to post comments on your behalf on Twitter. To post a comment on your behalf, assuming you have already logged in, TweetAppFiction will use your Twitter provided "Access Token" to allow you to post Twitter comments from TweetAppFiction.
References:
https://www.pingidentity.com/blogs/pingtalk/2012/05/The-simple-joy-of-understanding-OAuth.html
http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices
More Info:
Sahil Malik explains claims http://www.codemag.com/Article/1201021
Tip: Replace TweetAppFiction with an app you are happy to consider as your consumer/app. Examples of apps/consumer apps are TweetDeck and TweetApp.
Problem: So how OAuth shouldn't work: The end users signup with TweetAppFiction, TweetAppFiction asking the user for their Twitter, LinkedIn, Email etc. username and password. TweetAppFiction now can work on your behalf with Twitter and the other Service Providers you have given. The problem is you have given TweetAppFiction your full access credentials. You don't know or trust "TweetAppFiction". TweetAppFiction can now do any action it wishes against your Twitter account. Another issue is if TweetAppFiction gets hacked, your Twitter credentials are compromised.
OAuth/OpenId stops the end-users creating another set of credentials by allowing the Service Provider e.g. Twitter for another website. The end-user is directed to the Service Provider (twitter) where they authenticate themselves and tell the Service Provider (twitter) to allow this new web application to verify who they are (it also can give other permissions; in effect roles/services).
The issues OAuth solves for end-users are:
- TweetAppFiction does not have account credentials for your twitter account,
- TweetAppFiction will get access to do some actions on your behalf but you won't give it full permissions, and
- The end-user can revoke TweetAppFiction's permissions at any point from the Service Provider (Twitter),
- Authorisation (setup TweetAppFiction with limited permissions to Twitter)
- Usage (TweetApp will post/use Twitters API's)
Authorisation: This is the setup of allowing the consumer (TweetAppFiction) to use a Service Provider (Twitter) on your behalf to verify end users.
The end-user on the TweetAppFiction website/mobile app is going to create an account that logs you in using Twitter. TweetAppFiction will send your browser a URL that allows you to go to Twitter, and give TweetAppFiction permissions. If you are not already logged into Twitter you are prompted for your Twitter credentials. Once you grant the permissions, Twitter sends TweetAppFiction a token (this in effect is a set of credentials and roles for TweetAppFiction to use that is not your username and password but has a limited set of functionality it can perform on your behalf). Note: TweetAppFiction had to do an initial trust setup with Twitter that involves a Consumer Key & Consumer Secret (Think of this as the original trust relationship setup where Twitter is accepting TweetAppFiction to access TwittersOAuth API)/Resouce Server). OpenId does not need to perform this initial connection step (Google and Yahoo use OpenId).
Trusted Usage: For example, TweetAppFiction provides the ability to post comments on your behalf on Twitter. To post a comment on your behalf, assuming you have already logged in, TweetAppFiction will use your Twitter provided "Access Token" to allow you to post Twitter comments from TweetAppFiction.
References:
https://www.pingidentity.com/blogs/pingtalk/2012/05/The-simple-joy-of-understanding-OAuth.html
http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices
More Info:
Sahil Malik explains claims http://www.codemag.com/Article/1201021
0 comments:
Post a Comment