doktordirk
commented
8 years ago . But to be 100% correct and extensible, the property name should be defined in provider config block. When you use my auth0 provider you'll always find an id token in the access_token property, and I'd have named it id_token
ah, missed that part on gitter
This issue is only for putting together chat history on gitter channel re aurelia-authentication
30-may-2016
Paolo Furini @nexbit 15:57 @apawsey I was thinking of pluggable providers, I suggested them in this comment: https://github.com/SpoonX/aurelia-authentication/issues/146#issuecomment-222080830
Paolo Furini @nexbit 16:04 Today the providers are statically injected in the Authentication class, and I followed the same principle for my auth0 provider. But refactoring that class to get rid of static dependencies opens up the library to whatever provider you want to use
Wesley Overdijk @RWOverdijk 16:04 It's for one backend, but we could make multiple strategies I suppose I'm still a bit sick, so I'm still a bit slow :smile:
Paolo Furini @nexbit 16:06 Speaking of auth backends, we should make a distinction from standard flows and custom ones. Making providers pluggable for well-known flows, like OpenID connect, should be straightforward, but for completely custom flows that's another story..
Wesley Overdijk @RWOverdijk 16:07 That might be a good idea. Makes it easier to know what you should do
Paolo Furini @nexbit 16:17 Yeah, and one should reason about inputs and outputs.. What's important for an auth plugin is its ability to return tokens to the hosting app, and basically there are only two main types of tokens: bearer and id. The bearer token should be an opaque one, not to be consumed by the client app. The id token is usually a JWT and is consumed by the client, and sometimes passed to other server components
Wesley Overdijk @RWOverdijk 16:19 I have to admit that I don't use this I use basic jwt local strategy only So all I have is a refresh token and access token That's why my opinion on the matter is limited. But I'm glad you have one, that's good for the plugin. Pretty sure @doktordirk has one, too
doktordirk @doktordirk 16:21 what where why?
Paolo Furini @nexbit 16:22 I know but it's a bit confusing calling a JWT an access token.. At least when we have to deal with standard flows terminology..
Wesley Overdijk @RWOverdijk 16:23 @nexbit With basic jwt, the jwt is the access_token It also contains a payload, sure, but before unpacking it, it's just an access token.
Paolo Furini @nexbit 16:24 Yeah but when you enter OpenID connect that's become confusing..
Adam @apawsey 16:24 @nexbit pretty sure you need to point us all to a good resource to explain the differences... or you need to get typing and give us the breakdown :grinning:
Wesley Overdijk @RWOverdijk 16:24 +1 Love breakdowns Unfortunately I have to go. I have a meeting and after that another meeting with my bed to rest and get better.
doktordirk @doktordirk 16:25 re "providers are statically injected in the Authentication " i yeah, don't like that either
Wesley Overdijk @RWOverdijk 16:25 I'll catch up later :smile:
Adam @apawsey 16:26 @nexbit for example, I'm using identity server, and my config includes AccessTokenType = AccessTokenType.Jwt,
Paolo Furini @nexbit 16:36 @apawsey yeah you're right.. what I really mean is that normally the access token is opaque for the client, and it is used to flow it to other components (api for the major part). How this token is composed is up to the implementation, so using JWTs is a fair common practice
Adam @apawsey 16:37 @nexbit :grinning: thanks, but I've no idea if I'm right, that's my point, I'd love someone to give me the absolute truth breakdown or I guess more specifically, to help us/whoever include the proper behaviours in aurelia-authentication
Paolo Furini @nexbit 16:40 In addition, nothing prevents you to even inspect and somewhat consume the access token from your client, but that's irrelevant from the point of the auth plugin. Different story are id tokens, that should follow some stricter standards when you deal with OpenID connect flows. They are meant to be consumed even by the client, and they are always in the form of JWTs For example a proper id token must contain a sub property that uniquely identifies the subject (aka user) in the IDP But, in the end, it's not uncommon to use an id token both as a mean to identify the user and carry its claims, and at the same time use it as a bearer token for API authentication+authorization
Paolo Furini @nexbit 16:48 That's exactly the approach you should take when u use an external provider like Auth0. They architected their provider to always give you id tokens, and they tell you to just use them as bearer tokens also (https://auth0.com/docs/protocols#oauth-for-native-clients-and-javascript-in-the-browser)
Adam @apawsey 16:51 @nexbit well if I'm following you correctly, aurelia-authentication doesn't do thing perfectly then, because it does unpack the token to get the expiration time
Paolo Furini @nexbit 16:55 From http://oauth.net/articles/authentication/:
Sorry I messed it up :smile: The derive some information part is exactly what happens when you exchange an access token for an id token in OpenId connect Basically the access token is a token FOR THE IDP API ONLY It gives you a temporary key to further make requests to the IDP, that in terms of Oauth is simply another API, nothing special. OpenId gives you an endpoint to get you back an ID token (always a JWT with a sub property) that you must call with that opaque access token
Paolo Furini @nexbit 17:03 Based on all of this, when I think of an access token I think of an opaque token, and I do not expect or try to fiddle with it..
Paolo Furini @nexbit 17:13 To conclude this, things get a bit more complicated when you enter delegation. If you own the IDP or it gives you the ability to do so, you can flow the access token directly to your backend, and then your backend can query the IDP with that token to exchange it with another access token meant for another API, or group of APIs. Or the backend can query the IDP for the id token of the originating user, thus making the client application unaware of the user's identity..
Wesley Overdijk @RWOverdijk 20:13 That's a lot of text haha Before I dive into it, is there anything fundamentally broken in aurelia-authentication? Or is this just another way to do it, which might be prettier?
Paolo Furini @nexbit 20:32 @RWOverdijk no nothing really broken.. what I wrote is something that needs to be taken into account if/when restructuring the plugin for provider extensibility. Following standard naming conventions and refer to it in the docs should help other people working with it Now when the provider returns the response object, the property is called by default access_token, and one can change its name globally. But to be 100% correct and extensible, the property name should be defined in provider config block. When you use my auth0 provider you'll always find an id token in the access_token property, and I'd have named it id_token