Can you please add the explanation of all the claims of the access token from client id/secret such as scopes, issuer, sub etc, how are the attributes being used. Do they need to match what is specified on resources servers ? Or they are just some random string identifier? That would be helpful...
@@joshipiano authorization code flow always involves a natural person (therefore also called 3-legged OAuth) whereas client credentials flow is if the application is accessing the data on behalf of itself (like a service account for machine to machine communication). With client credentials flow you get the token directly from the token endpoint. There is no orchestration between the authorization server and the user.
I really don't understand. What is the difference between clientid/clientsecret and a username/password? Why can't a mobile app keep a secret? A mobile app can keep a password, right? Does this flow make sense if the authorization server and ressource server are the same application? Like in internal business apps?
Great short and concise video. Can you make a similar one but this time a deep dive about Client Credential Grant flow using a SSL certificate and making use of Client Assertions. (Instead of client secret) The benefits with using that.
Thank you for a great explanation and same for all your other great tutorials. I would like to ask for the 2 legged OAUTH example. Can the Authorisation server be in the client's realm/ domain? If so, then the resource server (I.e. Google Compute Engine in the example) would need to trust the Authorisation server and validate the Token? Also, we would configure PKCE in any case? Thank you. Tony
PKCE is only used for the authorization code grant because with the client credentials flow you directly get the token from the authorization server. The authorization server is typically in the same realm like the resource server or the resource server could also be run by some identity provider. Running the authorization server in the client's realm would only make sense if you are building a first party app
you do not need a refresh token with the client credentials flow because you are getting the token directly from the authorization server. The client credentials flow is designed for machine-to-machine communication. Refresh token only make sense if the user is involved, i.e. if you have a user sitting in front of an application and granting you limited access to an HTTP resource
What do you think about this explanation?
Was ist clear?
Can you please add the explanation of all the claims of the access token from client id/secret such as scopes, issuer, sub etc, how are the attributes being used. Do they need to match what is specified on resources servers ? Or they are just some random string identifier? That would be helpful...
The most straight to the point I have found! Thanks
Actually not very clear.. I think your PKCE video was way better... I mean how is the usecase1 different from normal auth code flow ?
@@joshipiano authorization code flow always involves a natural person (therefore also called 3-legged OAuth) whereas client credentials flow is if the application is accessing the data on behalf of itself (like a service account for machine to machine communication). With client credentials flow you get the token directly from the token endpoint. There is no orchestration between the authorization server and the user.
I really don't understand. What is the difference between clientid/clientsecret and a username/password? Why can't a mobile app keep a secret? A mobile app can keep a password, right?
Does this flow make sense if the authorization server and ressource server are the same application? Like in internal business apps?
"client secret for confidential servers only" Thank you.
👍
Great short and concise video. Can you make a similar one but this time a deep dive about Client Credential Grant flow using a SSL certificate and making use of Client Assertions. (Instead of client secret)
The benefits with using that.
Thank you for a great explanation and same for all your other great tutorials. I would like to ask for the 2 legged OAUTH example. Can the Authorisation server be in the client's realm/ domain? If so, then the resource server (I.e. Google Compute Engine in the example) would need to trust the Authorisation server and validate the Token? Also, we would configure PKCE in any case? Thank you. Tony
PKCE is only used for the authorization code grant because with the client credentials flow you directly get the token from the authorization server. The authorization server is typically in the same realm like the resource server or the resource server could also be run by some identity provider. Running the authorization server in the client's realm would only make sense if you are building a first party app
Thanks I was wondering if I should care about a refresh token or not
you do not need a refresh token with the client credentials flow because you are getting the token directly from the authorization server. The client credentials flow is designed for machine-to-machine communication. Refresh token only make sense if the user is involved, i.e. if you have a user sitting in front of an application and granting you limited access to an HTTP resource
anda perlu melaraskan kandungan
Posting context dependent video tutorials to youtube in small clips isn't the most helpful thing in the world