- 153
- 1 351 656
Jan Goebel
Germany
เข้าร่วมเมื่อ 6 ม.ค. 2019
Building real-world, production-ready applications. Opinions are my own.
Portfolio: jangoebel.com
Blog: productioncoder.com
Portfolio: jangoebel.com
Blog: productioncoder.com
OAuth 2.0 - a dead simple explanation
X: _jgoebel
Website: jangoebel.com
00:00 What is OAuth 2.0?
00:13 What problem does OAuth 2.0 solve?
02:04 OAuth 2.0 Client Registration
03:06 OAuth 2.0 Confidential vs. public clients
04:21 OAuth 2.0 Authorization Code Grant
06:43 OAuth 2.0 Access and Refresh Tokens and JWTs
08:03 OAuth 2.0 Grant types: client credentials grant, implicit grant, resource owner password grant, device grant
09:03 Outro
OAuth 2.0 is an "authorization framework [that] allows third party applications to get limited access to an HTTP service" (RFC 6749).
OAuth 2.0 is all about giving third party applications limited access to APIs. Prior to OAuth 2.0, the third party would have asked for the user's credentials and would have used these credentials on the respective API. OAuth 2.0 eliminates the need for password sharing by introducing a new entity called the OAuth 2.0 authorization server.
The OAuth 2.0 authorization server issues access and refresh tokens to third party applications thereby eliminating the need of credential sharing. The third party application is called the client in OAuth terminology. The API the third party wants to get access to is called the resource server or the protected resource.
Before a third party can get limited access to an API, it first needs to register itself with the OAuth 2.0 Authorization server. The third party application, the so called client, gets a client id upon registration with the OAuth 2.0 authorization server. If the client can keep data secret, then it will also obtain client credentials. The simplest form of a client credential would be a shared secret called the client secret. OAuth 2.0 also supports more sophisticated means auf authenticating against the OAuth 2.0 authorization server such as mutual TLS (mTLS).
Once the client is registered, the client performs one of the OAuth flows that are also known as grant types. The most popular grant types are the OAuth 2.0 authorization code grant which orchestrates an approval flow between the resource owner, the OAuth 2.0 authorization server and the protected resource.
Contrast this with the client credentials grant which is made for machine-to-machine communication. The resource owner password grant and the implicit grant are insecure according to the OAuth 2.0 Security best current practices and must not be used. Then there is also the OAuth 2.0 device grant which is built for devices that do not have a browser or where entering credentials is cumbersome such as Smart TVs.
While the OAuth 2.0 RFC does not mandate the access and refresh tokens to be structured, in most deployments they are actually JSON Web Tokens (JWTs). This has the advantage that the protected resource can validate the signature of the token locally without having to make a REST call to the authorization server to check for the validity of the token.
Picasso Artwork: www.freepik.com/free-vector/hand-drawn-picasso-style-illustration_29679617.htm Image by Freepick
Artist: www.freepik.com/free-vector/artist-art-tools-set_3813261.htm Image by macrovector on Freepick
Software Engineer: www.freepik.com/free-vector/binary-code-concept-illustration_15581993.htm Image by storyset on Freepick
Website: jangoebel.com
00:00 What is OAuth 2.0?
00:13 What problem does OAuth 2.0 solve?
02:04 OAuth 2.0 Client Registration
03:06 OAuth 2.0 Confidential vs. public clients
04:21 OAuth 2.0 Authorization Code Grant
06:43 OAuth 2.0 Access and Refresh Tokens and JWTs
08:03 OAuth 2.0 Grant types: client credentials grant, implicit grant, resource owner password grant, device grant
09:03 Outro
OAuth 2.0 is an "authorization framework [that] allows third party applications to get limited access to an HTTP service" (RFC 6749).
OAuth 2.0 is all about giving third party applications limited access to APIs. Prior to OAuth 2.0, the third party would have asked for the user's credentials and would have used these credentials on the respective API. OAuth 2.0 eliminates the need for password sharing by introducing a new entity called the OAuth 2.0 authorization server.
The OAuth 2.0 authorization server issues access and refresh tokens to third party applications thereby eliminating the need of credential sharing. The third party application is called the client in OAuth terminology. The API the third party wants to get access to is called the resource server or the protected resource.
Before a third party can get limited access to an API, it first needs to register itself with the OAuth 2.0 Authorization server. The third party application, the so called client, gets a client id upon registration with the OAuth 2.0 authorization server. If the client can keep data secret, then it will also obtain client credentials. The simplest form of a client credential would be a shared secret called the client secret. OAuth 2.0 also supports more sophisticated means auf authenticating against the OAuth 2.0 authorization server such as mutual TLS (mTLS).
Once the client is registered, the client performs one of the OAuth flows that are also known as grant types. The most popular grant types are the OAuth 2.0 authorization code grant which orchestrates an approval flow between the resource owner, the OAuth 2.0 authorization server and the protected resource.
Contrast this with the client credentials grant which is made for machine-to-machine communication. The resource owner password grant and the implicit grant are insecure according to the OAuth 2.0 Security best current practices and must not be used. Then there is also the OAuth 2.0 device grant which is built for devices that do not have a browser or where entering credentials is cumbersome such as Smart TVs.
While the OAuth 2.0 RFC does not mandate the access and refresh tokens to be structured, in most deployments they are actually JSON Web Tokens (JWTs). This has the advantage that the protected resource can validate the signature of the token locally without having to make a REST call to the authorization server to check for the validity of the token.
Picasso Artwork: www.freepik.com/free-vector/hand-drawn-picasso-style-illustration_29679617.htm Image by Freepick
Artist: www.freepik.com/free-vector/artist-art-tools-set_3813261.htm Image by macrovector on Freepick
Software Engineer: www.freepik.com/free-vector/binary-code-concept-illustration_15581993.htm Image by storyset on Freepick
มุมมอง: 28 034
วีดีโอ
What is the difference between a PUT and a PATCH request?
มุมมอง 10K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com PATCH RFC: datatracker.ietf.org/doc/html/rfc5789#section-9.1 The PUT HTTP verb is used to create or replace the resource under a specific URI completely. In case the resource under a particular URI already exists, it will be completely overwri...
What is a hash function?
มุมมอง 3.4K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com A hash function is a function on a bit string that produces an output of fixed length. The goal of hash functions is to avoid collisions as much as possible. Typically the moment a collision is found in a modern hash function, this particular ...
What is the difference between data authenticity and data integrity?
มุมมอง 1.4K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com Data Authenticity is the property that data comes from its purported source. Data Authenticity is violated if a message is not coming from the person you expect it to come from. Data Integrity is the property that data has not been altered or ...
What's the difference between Authentication vs Authorization?
มุมมอง 3.7K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com Authentication is the process of verifying the identity of a user, process or device, often as a prerequisite to allowing access to resources in an information system. If you are trying to enter a country, the border officer is essentially per...
What is the difference between URI, URL and URN?
มุมมอง 6K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com URN RFC: datatracker.ietf.org/doc/html/rfc8141 URI RFC: datatracker.ietf.org/doc/html/rfc3986 00:00 What is a URI? 00:39 What is a URL? 01:13 What is a URN? URI stands for Uniform Resource Identifier and is an identifier for a physical or abst...
OAuth 2.0 Pushed Authorization Requests
มุมมอง 4K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com PAR RFC: www.rfc-editor.org/rfc/rfc9126.html When authorizing a natural person with the authorization code grant in OAuth 2.0, the initial request parameters are sent via the browser's bar (front channel). This poses several challenges 1. no a...
OAuth2 Resource Indicators
มุมมอง 1.5K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com Resource Indicators RFC: datatracker.ietf.org/doc/html/rfc8707 00:00 What are OAuth2 resource indicators and why are they useful? 01:50 OAuth 2.0 Resource Indicators with JWTs 04:07 Conclusion Resource Indicators are a way for an OAuth2 client...
OpenID Connect client authentication: client_secret_jwt and private_key_jwt
มุมมอง 5K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com OpenID core spec: openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication 00:00 client authentication for confidential clients in OAuth 2 and OpenID Connect 01:10 OpenID Connect client_secret_jwt client authentication 03:53 OpenID C...
OpenID Connect client authentication: basic auth and client secret post
มุมมอง 2.9K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com Link to OAuth 2.0 Core RFC: datatracker.ietf.org/doc/html/rfc6749#section-2.3 00:00 Client Authentication in OAuth and OpenID Connect 00:28 Using HTTP Basic Auth (client_secret_basic) to authenticate to the authorization server 01:01 client_se...
OAuth 2.0 mutual client authentication (mTLS)
มุมมอง 10K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com OAuth mTLS RFC: tools.ietf.org/html/rfc8705 00:00 Client Authentication between client and OAuth authorization server 01:41 OAuth 2.0 mutual TLS (mTLS) 04:43 OAuth 2.0 Certificate-Bound Access tokens with mutual TLS 05:59 Binding an access tok...
OAuth 2.0 JWT-secured Authorization Requests (JARs)
มุมมอง 3.7K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com JWT-secured authorization requests RFC: datatracker.ietf.org/doc/html/rfc9101 00:00 Introduction to authorization requests in OAuth 01:37 What are JWT-secured authorization requests? 02:32 Using JWEs to encrypt authorization requests 04:24 JWT...
What are Bearer Tokens?
มุมมอง 26K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com OAuth 2 Bearer Token Usage: datatracker.ietf.org/doc/html/rfc6750 00:00 What are Bearer tokens? 01:43 Proof of Possession would increase security Bearer tokens are commonly used for authorization and authentication on the web. If a token is a ...
OAuth 2.0 Dynamic Client Registration Management
มุมมอง 2K2 ปีที่แล้ว
🔥More exclusive content: productioncoder.com/you-decide-what-we-build-next Twitter: _jgoebel Website: jangoebel.com Blog: productioncoder.com OAuth Dynamic Client Registration Management Protocol: datatracker.ietf.org/doc/html/rfc7592 00:00 What is OAuth Dynamic Client Registration Management? 01:01 OAuth Client Configuration Endpoint and registration access token 01:40 Reading, upd...
Unsecured JWTs are a huge security vulnerability
มุมมอง 1.3K3 ปีที่แล้ว
Unsecured JWTs are a huge security vulnerability
HTTP structured field values: standardizing HTTP headers and trailers
มุมมอง 5713 ปีที่แล้ว
HTTP structured field values: standardizing HTTP headers and trailers
OpenID Connect vs OAuth | OpenID Connect explained
มุมมอง 42K3 ปีที่แล้ว
OpenID Connect vs OAuth | OpenID Connect explained
HS256 vs RS256 with JSON Web Tokens (JWTs)
มุมมอง 3K3 ปีที่แล้ว
HS256 vs RS256 with JSON Web Tokens (JWTs)
thank you sir
Good Stuff
Glad you enjoyed
Done thanks! HMAC or RSA can be used for the signature If using HMAC then need to share the secret used to sign if you want to verify the signature which is risky if only the issuer that issued the token needs to verify its integrity then they already have their own secret no need to share it but if you want the receiver of the jwt to confirm that it was issued by you then use rsa for signature so they can verify with your public key With RSA the token signature can be verified with the public key without knowing private key of the token issuer So can confirm that token was issued by a specific issuer if you know their public key
yep, that pretty much sums it up.
Done thanks RSA can be used to create the signature also, signing with private key HMAC can also be used to create the signature Elliptic curve cryptography can also be used
Jwt uses hmac function message authentication code
Done thanks Audience is the claims body of the jwt identifies who the token is intended for (who’s using the token) and issuer is who signed the token (the server issuing it)
Done thanks! With regular jwt, the content is just base 64 url encoded so anyone can read the contents (but the issuer attaches a signature made of the header, claims (body) and appends it to the token to verify integrity. JWE is like jwt but the body is encrypted, so when you made 64 url decide it, you can see the body as cipher text and only issuer can read it
Done thanks! 1:00 You base 64 url encode the header and the claims (body) and generate a digital signature with those two and your secret_key of the server issuing the token You the concatenation the signature also so the final token is header, claims and signature concatenation with .
Good explanation. Naive question. Isnt it possible for a malicious app to cache all the communication which means also the hash code and the string as soon as i send it to the auth server for authentication? Im aware this is a naive question, i just want to understand it fully :)
Appreciate it for sharing! Hoping for some advice: My wallet on OKX contains some Tether USDT, and I possess the recovery phrase: ▲clean▲ ▲party▲ ▲soccer▲ ▲advance▲ ▲audit▲ ▲clean▲ ▲evil▲ ▲finish ▲tonight▲ ▲involve▲ ▲whip▲ ▲action▲. Could you suggest how should I go about transferring them to Binance?
Perfect!
Thank you very much!
You're welcome!
Hi, after the user successfully login, why google don't just give the user access_token? Why google give auth_code, and then we request access_token using auth_code? I'm kinda lost in here. Can you help me to explain? Thank you
what you describe is called the implicit grant which is marked as must not use according to the OAuth security current best practices. The issue with this is that the token would be in the URL. This is problematic because it is visible in the browser's history and also the URL might be passed when to user goes to another website as part of the Referrer header. Therefore, the OAuth authorization code grant (which is what you should use) uses a one time coupon so to say to obtain the access token to prevent this
What an amazing explanation! Thank a lot! 🙇 Fabulous animations!
Glad you liked it!
Really simply explained. Seen some much more complex explanations of something that is really pretty staright-forward.
Glad you liked it!
Nice. But I'm looking for a way to generate that schema from an open api spec. This way, it would all depend on the spec. Is there a way to do it?
Saying "should not use" and "anti-pattern" is a huge stretch. You should clarify the context cause if the audience is the issuer such as the case with first-party apps, then it's perfectly valid. Not every OAuth flow is about a service to another, where Authorization Flow would of course be better.
Thank you for your efforts and time ^^.
Glad you liked it!
Yeah that's me. I know all these things are important but too comfortable with my job to actually go do them.
What a splendorous video. Thank you so much!
thank you
You're welcome
thank you so much for this video .
You are most welcome
after knowing jwt is not that kinda secure enough: 💀💀
sexyyyyyyyy
Awesome video, man. Congratulations.
Glad you enjoyed it!
Simple straight to the point explanation! Thanks.
Glad you liked it!
👍
🤙🤙
👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌👌🧙♂🌐🛰🎣👑 you nailed it thank you so much
Thank you ! For me I understand the principle (listening at 0.75 speed) but I don't see why the attacker cannot intercept a normal request to the resource server where the access token and the original PKCE are sent, and intercept and get the PKCE code (original) there. With that, it can then itself request authentication (an auth token), for example he can intercept both authentication and authorization requests to get the mix of parameters he needs to act on behalf of the user. Isn't this possible?
This is a gem! Thank you for this video!
Great job explaining the pieces of a HMAC and the practical use cases. Thank you!
awesome explanation and presentation, new sub :)
Glad you liked it!
If anyone is looking for a simple schema validation library checkout "jet-schema"
Thanks for sharing such valuable information! I have a quick question: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
Thank you Jan
you're most welcome David
Thanks
Spring has webflux for streaming (now virtual threads but they werent available at the time of this video so leave that aside), why was that not brought up? A steeper learning curve is absolutely a valid criticism but you're just ignoring functionalities. Kind of questioning your knowledge on these environments
Well explained, Thank you!
Glad you liked it!
great!
Great explanation. Thanks
Glad you liked it!
well explained, thank you!
Thank you so much for the great explanation!
What if there are nested objects or arrays ? Or the entities are always 1 level ?
doesn't matter. PUT always replaces the entire thing
HI Great explanation, can you give me your diagrams to learn from it, please
Furman Forks
Aida Stravenue
Schowalter Mission
Halie Valley
Rebeca Island