A while ago I wrote a controversial article about the problems that can arise when mixing authentication and authorization systems – especially when using identity/access tokens to transmit authorization data – you can read it here.
In the meanwhile Brock and I sat down to prototype a possible solution (or at least an improvement) to the problem and presented it to various customers and at conferences.
Also many people asked me for a more detailed version of my blog post – and finally there is now a recording of our talk from NDC – video here – and slides here. HTH!
leastprivilege.com 
Thank you for this. I really enjoyed the talk, and have been trying to find some early code on the authorization server you presented. Do you have any info on whether you plan to publish any of that in the near future?
We are not sure yet how we gonna release this.
Hi Mr. Dominick,
Do you recommend Windows Authorization Manager (AzMan) as a the authorization provider you mentioned in?
AzMan is a very old COM component – no wouldn’t recommend it.
Thanks !
Whats is the alternative, please?
I have none – we built our own as shown in the video
I enjoyed this very much also, I’m really looking forward to you releasing it in the future – hope it’s soon! One question: with all this work to separate authentication from authorization, it got me thinking about scopes – ‘AllowedScopes’ in IdentityServer, or the ‘aud’ metadata element in your presentation. Maybe you’ve discussed this in the past, but scopes allow me to say user X has access to ‘Api1’, but not ‘Api2’, correct? If so isn’t this more about denoting what you have access to, not who you are? Isn’t that actually authorization, technically speaking?
Scopes are not for authorizing users – they are for granting clients access to certain functionality.
“….granting clients access to certain functionality.” Not trying to be picky, but how is that different from authorization? Maybe i’m missing a concept here…
Scopes are for when the client needs to ask you for consent to do something on your behalf. So in a way you’ll be authorizing the client and not the other way around. For example, you can consent to a scope that allows authorized users to draw money out of your PayPal account.
Thanks for the great talk! I’m really looking forward to some preview of the code you guys have once it’s ready :-)
In the talk you said that you’d use the identity token to fetch authorization information but where does that leave the access token? Should the identity token be used to get/post data from/to an Api?
Thanks for all the work you guys put in making authentication and authorization easier!
Did I say “id_token” ? – What I meant is “identity”
Thank you for great talk. I am one of those guys who uses it wrong, and I still have my doubts on how this suppose to work in distributed system which consists of composite UI and bunch of publicly available services.
Here are details. Sorry for lot of text, just trying to make it clear.
There are multiple teams in my company developing multi-tenant services, using different technologies, hosted separately (“microservices”). Customers manage these services via Customer Console which is a composite UI, a browser framework hosting multiple browser apps (say, Angular apps). This is an open system, partner services will be added to the mix eventually.
Using it “wrong”, it is easy to manage and enforce authorization. Service developers register their scopes with my OP, my Authorization Management UI allows combining scopes into roles, and assigning roles to users. When user signs in, they get a reference token with scopes and claims combined from all roles (roles are not included in tokens). Browser client calls services (sometimes layered). Token validation in service is very straight forward: standard token validation + finding relevant scopes. Piece of cake.
Using it “right” requires all my services to implement some authorization logic taking token and operation as input parameters, perhaps expressed via a policy. These policies must be centrally managed and distributed to services. So now i have added complexity in my system without added benefit:
1. In addition to scope assignment to users/client, I have to manage and distribute policies (using XACML I guess).
2. All my services implemented in different technologies must have an ability to execute these policies. This includes services implemented by our partners as well. Authorization enforcement now becomes an expensive effort.
Am I missing something? Thanks in advance, and thank you for your great work!
Thanks!
I don’t know if you are missing something. I would need more context.
Scopes to roles mapping sounds definitely wrong to me – since scopes are not a user concept but a client concept.
Is there already an GitHub repository available? I want to take a look at it and help to extend and improve it.
Thanks – but this is private for now.
Any ETA? We’re starting a new project and we’d like to know if we can wait for your code or implement our own.
Thx!
This code won’t be public – it’s for customers only. You can become a customer – contact us via identity@leastprivilege.com
Loved the talk and the ideas you guys provided!!