Hi Justin ... In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token.
<acl> this is the part I'm missing. I understand how to get the authorization code to the client ... I think what you're saying is that when the client present the access code to the token endpoint, that the token endpoint can return either a SAML or JWT token? Is the token endpoint typically part of the Authorization Server? Is the type of token returned (SAML/JWT/etc) depending on the implementation and what is supported by different vendors and open source, or is this required by the standard? OAuth 2.0 doesn't really say a whole lot about the actual access token. Is this all considered out of band from OAuth and a matter of implementation? Btw ... I currently have two OAuth implementations running in the lab ... an evaluation copy of PingFederate and an open source stack (OpenAM). </acl>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
