OAuth in the new .NET world (OWIN)
•Als PPTX, PDF herunterladen•
3 gefällt mir•7,724 views
Basic introduction to OAuth, and how it works in the new .net ecosystem, through OWIN and the Authentication Middleware
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (14)
Ähnlich wie OAuth in the new .NET world (OWIN)
Ähnlich wie OAuth in the new .NET world (OWIN) (20)
Mehr von Emad Alashi
Mehr von Emad Alashi (12)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
OAuth in the new .NET world (OWIN)
- 1. Emad Alashi • Senior Developer at Readify • ASP.NET/IIS MVP • www.DotNetArabi.com • www.EmadAshi.com • @emadashi 1
- 2. OAuth 2.0 & .NET Live with others 2
- 4. Images data Resources email Username & password Username & password Etc. Username & password Username & password Username & password 4
- 5. Facebook Auth Flickr API Yahoo BBAuth Web Services Google AuthSub 5
- 6. 6
- 7. So how does it work? 7
- 8. Resource owner Authorization Server Authorization/Resources Server Client Resource Server 8
- 9. myPodcast.com 302 to fb.com/auth? data auth? clientID & scope & redirectUri=myPD.com/signin This app wants…are you sure? Yes please, allow myPD.com/signin? code & scope 302 to myPD.com/signin? data Welcome fb.com/auth? clientId & code & redirectUri accessToken & tokenType & expires & refreshToken 11
- 10. OAuth in MVC 4 DotNetOpenAuth & OAuthWebSecurity 12
- 11. OAuth in MVC 5 OWIN 13
- 12. owin.org 14
- 13. OWIN (Open Web Interface for .NET) 15
- 14. OWIN with IIS 16
- 15. Middleware 1 Invoke(IOwinContext con) { DoINeedToAlterRequest? { } Middleware 2 Middleware 3 AllowSubsequentMiddleWares? { base.Next.Invoke(con); } NeedToAlterResponse? { } } 17
- 19. Cookies middleware Facebook middleware Application Post: myPd.com/Account/Login(Facebook) 302 to Fb.com/oauth?redirectUri=signin-facebook ApplyResponseChallenge 302 to fb.com/oauth 401 (facebook) Get: myPd.com/signin-facebook?code=djlsjjce AuthenticateCoreAsync ---Create Idnetity 302 to Account/External 302 to myPD.com/Account/External Get: Account/External ApplyResponseGrant -----wrap claims in App ticket Create cookie SignInExternal ---Create Idnetity 21
- 20. Oauth Server mid. /auth?clientId&Response_Type /token?code=tyggyug redirectUri?token=uhuihuhkn aPage AuthHead: Bearer ygugjygj Invoke --validations Oauth Auth mid. signIn Application signIn ApplyResponseGrant AuthenticateCoreAsync 22
- 22. Authentication Middleware • Facebook • Google • Twitter • OAuth • Server • Authentication 24
Hinweis der Redaktion
- What we will learn today:What is OAuth (Intro)The new authentication model of MVC 5 & OWIN and how it relates to OAuthThe .net components Microsoft put that deals with OAuth like Facebook authenticationNote:We will be fast
- Everyone had access to your entire resources unconditionedIncluding the fool and the evilOnce in their hands, can never revoke their access unless you change the password
- OAuth started 2006Blain Cook (Twitter)Chris Messina Larry HalffDavidRecordonEran HammerLater in 2008 it moved under the umbrella of Internet Engineering Task Force (IETF)
- Authorization CodeThe authorization code is obtained by using an authorization serveras an intermediary between the client and resource owner. Instead ofrequesting authorization directly from the resource owner, the clientdirects the resource owner to an authorization server (via itsuser-agent as defined in [RFC2616]), which in turn directs theresource owner back to the client with the authorization code.Before directing the resource owner back to the client with theauthorization code, the authorization server authenticates theresource owner and obtains authorization. Because the resource owneronly authenticates with the authorization server, the resourceowner’s credentials are never shared with the client.The authorization code provides a few important security benefits,such as the ability to authenticate the client, as well as thetransmission of the access token directly to the client withoutpassing it through the resource owner’s user-agent and potentiallyexposing it to others, including the resource owner.1.3.2. ImplicitThe implicit grant is a simplified authorization code flow optimizedfor clients implemented in a browser using a scripting language suchas JavaScript. In the implicit flow, instead of issuing the clientan authorization code, the client is issued an access token directlyHardt Standards Track [Page 8]RFC 6749 OAuth 2.0 October 2012(as the result of the resource owner authorization). The grant typeis implicit, as no intermediate credentials (such as an authorizationcode) are issued (and later used to obtain an access token).When issuing an access token during the implicit grant flow, theauthorization server does not authenticate the client. In somecases, the client identity can be verified via the redirection URIused to deliver the access token to the client. The access token maybe exposed to the resource owner or other applications with access tothe resource owner’s user-agent.Implicit grants improve the responsiveness and efficiency of someclients (such as a client implemented as an in-browser application),since it reduces the number of round trips required to obtain anaccess token. However, this convenience should be weighed againstthe security implications of using implicit grants, such as thosedescribed in Sections 10.3 and 10.16, especially when theauthorization code grant type is available.1.3.3. Resource Owner Password CredentialsThe resource owner password credentials (i.e., username and password)can be used directly as an authorization grant to obtain an accesstoken. The credentials should only be used when there is a highdegree of trust between the resource owner and the client (e.g., theclient is part of the device operating system or a highly privilegedapplication), and when other authorization grant types are notavailable (such as an authorization code).Even though this grant type requires direct client access to theresource owner credentials, the resource owner credentials are usedfor a single request and are exchanged for an access token. Thisgrant type can eliminate the need for the client to store theresource owner credentials for future use, by exchanging thecredentials with a long-lived access token or refresh token.1.3.4. Client CredentialsThe client credentials (or other forms of client authentication) canbe used as an authorization grant when the authorization scope islimited to the protected resources under the control of the client,or to protected resources previously arranged with the authorizationserver. Client credentials are used as an authorization granttypically when the client is acting on its own behalf (the client isalso the resource owner) or is requesting access to protectedresources based on an authorization previously arranged with theauthorization server.
- The flow illustrated in Figure 3 includes the following steps:(A) The client initiates the flow by directing the resource owner’suser-agent to the authorization endpoint. The client includesits client identifier, requested scope, local state, and aredirection URI to which the authorization server will send theuser-agent back once access is granted (or denied).(B) The authorization server authenticates the resource owner (viathe user-agent) and establishes whether the resource ownergrants or denies the client’s access request.(C) Assuming the resource owner grants access, the authorizationserver redirects the user-agent back to the client using theredirection URI provided earlier (in the request or duringclient registration). The redirection URI includes anauthorization code and any local state provided by the clientearlier.(D) The client requests an access token from the authorizationserver’s token endpoint by including the authorization codereceived in the previous step. When making the request, theclient authenticates with the authorization server. The clientincludes the redirection URI used to obtain the authorizationcode for verification.(E) The authorization server authenticates the client, validates theauthorization code, and ensures that the redirection URIreceived matches the URI used to redirect the client instep (C). If valid, the authorization server responds back withan access token and, optionally, a refresh token.
- KatanaAuthentication is a Middleware
- Invoke: Check if should handle or notAuthenticateCore: create Authentication Ticket (Identity wrapper)ApplyResponseGrant: add token, remove tokenApplyResponseChallenge: handle 401