BSidesSF 2026 - Breaking Tokens: Modern Attacks on OAuth, OIDC, and JWT Auth Flows (Bhaumik Shah)

So for our last but certainly not the least session of the day we have Bik Sha. He will be talking on breaking tokens modern attacks on oath OIDC and jot o flows. As a reminder we'll be doing Q&A through slido. So if you haven't already found it through the QR code you can go to bsidesf.org/q&a. Post your questions there and we'll be going through them at the end of the session. With that over to you Bame. >> All right. Thanks Ky. So good afternoon everyone. Uh I know it's the last talk of the day. Let's bring some energy to the talk. I know it's going to be really technical and somewhat important topic. If you guys are using oath or oidc in

your systems or application. So before we start I want to start with uh one of the uh like you know breach which was happened in 2025. I don't know how much of you are aware of that there was a Salesforce Ooth token breach and what happened there was there was a uh one of the integrations which was done uh by provided by the Salesforce and one of the token through that integration it was trusted integration and that that integration token got breached. Now because the scope of the token was so huge in terms of like not narrowly scoped the attackers were able to log in or access 7,000 plus customer environment just because of the tokens

and this is this was like widely exploited last year and we'll we'll I'll show you a couple more examples which were exploited using some of these techniques uh and and why we need to worry about this. Another thing uh probably you want to make a note of uh so token is like you know how I see it token as a currency. So for example whoever has the token or whoever has the currency can spend it. So if you can forge it you can replay it you can trick someone uh to trust on like you know make believe that this is like you know a real token or real currency and then you can do all kind of system attacks.

Uh before we uh go further into technical nitty-gritty uh just quick intro on myself. So I'm a founder of security AI. Uh previously I had worked at AWS Fire World Bank as a security uh guardian and working at like you know challenging uh solving some security challenges. Uh I have totally uh 17 plus years of experience working in identity systems, cloud and infrastructure and occasionally as and when I get a time I drop some security insights on my YouTube channel called cyberc TV. Here's the quick refresher on how oath login flow works. I guess most of you probably already know uh and and I'm I'm hoping that you are using OOTH uh like single sign on in your day-to-day

application somewhere uh on production at this point. So the simple flow works like this. So you have the client app, you have identity provider in the middle and then you have the backend system uh which like you know has all the critical data. So your client app sends a request to the identity provider that could be your Google single sign on, octa, ozero, uh anything Azure. Then it validates the user. It gives you the oat token or ID token. Once you get the token, you whatever the information as a client or user you need, you pass it to the backend server. The backend server validates a token and you get the response or whatever the

request was. Right? So this is a simple login flow. Um now we're going to talk about u like you know where the issue is. So here in the modern systems security decisions are not made by a like you know just like our traditional system where we had like one authorization server where we keep all the like you know session information and gets validated and make a decision. It doesn't happen like this. You have the user then identity provider like we saw in the previous slide and then after the front end gets the token it passes to the back end API microservices mobile application passes through the au like you know APIs. So there are lot of

different systems and making security decisions and this is in a simple app right like if you talk about a system like AWS or or Azure like which are complex enterprise systems you have different different systems like within system and then all of them are making secure decisions based on the token and then they have to validate each system has to validate what is the scope of the token what is the signature of the token whether it's valid or not whether the token was issued by the to the correct user or not user identity whether it has been forged or not. So all of these system has to make the decision and if even if one system does

not make the right decision the entire identity system collapses. So let's take a look at the uh first scenario uh we had. So here we are going to talk about like breaking microservices with the token replay. So this is the this is the real uh like you know application which probably I was testing uh some time ago and this was a financial application. Of course this is not the full architecture of the system but very high level. So on the left hand side as you can see there's a client and then there is a reverse proxy or we can call it as a gateway where all the token validation uh takes place and once the gateway validates the token

it routes the request to different services like you can think of this as like you know lambdas uh little lambdas you have post the gateway so you have account service you have transaction service then there is also internal services and configuration service now gateway way. What it does is it accept the token. It checks where the request to route and it routes us routes the ser uh request accordingly. What could go wrong here? So you have the client making the request to the gateway. Gateway val the token and it routes to the account service. Now as an attacker my goal is obviously to escalate my privilege and try to access something which I don't usually have. So

I'll try to access let's say some internal service which is behind this uh like you know public services or maybe exposed on the internet but not visible to me. So for example if you if you log into certain application you could only go to the endpoints which are exposed and you can see in the API documentation or or swagger etc. But there are some services which is behind this which is not exposed not documented but you can still expose. And another thing as an attacker you want to make sure is whether you can use the same token, you can replay the token to access those. So I have built like a little demo and if you if you want to try this out

yourself, you can also do it. It's hosted on oath lab at sec.securify.co. So you can try it out. Just the interest of time, I have pre-recorded, but I'll walk you through how this attack usually works. So first of all uh you can think of this as a like you know your login let's say this is an octa or ozero login page as a user you would put your credentials which is quite normal and once you put the credentials it will take you to the whatever the user profile page or your dashboard page uh it's a banking application so whatever the page right like it it just takes you after the authentication post that as an attacker my curiosity is

is there anything beyond this which I can see and I can like you know enumerate within the application. So now what I'm doing is probably if you don't know this is the proxy tool called burpuite uh which has a which has a uh a feature called repeater. So you can repeat the request as many times as you want. So I'm sending the request to the repeater just to find out what are the other endpoints which are behind this application and also how the application is validating the token. So as you know I have removed the authorization token and if I send the request of course I should expect the error not authorize. So which is expected. Now what I'm

trying to do is I'm trying to escape the micros service which I was accessing. So for example if I was on the page called user profile uh this is sort of like a you can think of this as a directory traversal or uh enumeration. Uh burp intruder also has like you know a lot of this uh u kind of a list available. You can automate this as well. So I'm just trying to enumerate until I find some internal service. So here at this level we saw that there is a change in the header. So earlier it was if you notice it was express js and now we saw it's a Django 4.2.17. So that means now there is some service

running behind this gateway but not accessible to us directly. Now once as an attacker you access this the only thing you have to do is you have to figure out like right endpoint which is like you know in the Django example this is API o users is a standard endpoint that they use to pull all the user list like super admin etc. So once you pass this information of course you still have to provide the authentication token and hopefully I can use the same one which I had previously uh which was issued to access me like you know the basic transaction service for for instance or a public uh API and I'm replaying the same token which gets

me access to the Django admin as well. So here I'll all right so here there are two problems uh so here from this attack there are two takeaways one for each token you need to check as a let's say if I if I were the developer I would make sure that the what's the scope I have defined for each token whether the token is just meant for the internal service or external service transaction service configuration service whatever that is you can be as granular as you want or as you need because you cannot not leave it up to the gateway or an application to define whether this they're going to validate whether the token will work or not because once the

it passes the gateway the token can access pretty much anything and that's what happened in the Salesforce as well because when the attacker got this token from the integration which was trusted that token had a wider scope and that allowed access to all the customer instances and then secondly for the internal uh let's say you have like you know some internal service which is running behind the gateway you can use probably separate o configuration you can use like let's say octa for your external or you can use u ozero for internal or you can create like you know your internal IDP as well by having the separate o configuration like client ID and and client ID registration this will

segregate your it's just like segregation of test and production environment like you don't mix it up so Same way you do not want to mix up like internal and the external uh system that microservices that you have and authentication and if you do then yeah just make sure the scope is really really granular. So that's the first check I would do uh based on this learning. All right. Uh second scenario we had was the better token replay and here the token is valid but the user is not valid. Right. So I don't know how many of you remember this storm 2372 attack uh which had happened uh again last year. Uh Microsoft uh was the

victim here. So in this one the group of attackers had created like a fishing scenario where it would send a link to the user. User opens it up. It looks everything like Microsoft. They put their MFA code in and once the they put the password and multiffactor authentication the token goes to the attacker and now attacker just uses the token to access their Microsoft account. So the critical part here is the token was with the attacker even though it was like you know the user put the credentials the user put the uh uh MFA multiffactor but the eventually the token was acquired by the attacker. So then and the attacker was able to use the token because it was not bound to a

device like any person who has the token can use it just like a currency. It was not tied to a s session and it could you can use it from any other system doesn't matter what the geocation is and even though the authentication had multiffactor authentication right so like once you put the password you have multiffactor but that stop step is gone like after that step there's no validation so once the user generates the token the the token has no relevance whether it was done like you know gone through the multiffactor or not So once you steal the token you can reuse it anywhere. Now many of you would think this is similar to like session hijacking. Um it

is like more or less it's like you know in the traditional term we can call it as session hijack. So in the traditional hijack you have a attacker then you have like you know a session cookie which is stored in your browser cookie manager and then attacker like you know somehow steals the cookie and and replay it on their application and gets the access in the SSO token hijacking. Uh the only difference I would say is uh as you probably saw in the previous slide as well. So once you grab the token uh of course attackers still have to steal the token like what they did in the Microsoft scenario. They still have to steal the token but once they steal the

token they can access more than one service. They can access like you know not just the this token is not tied to a a simple application. It's tied to like you know all the integrations that you have your application provides. It's also tied with all the all the services internal services you have. So depending on the scope of the token the the blast radius is is pretty huge compared to the session hijack. All right. So here in this demo uh we are going to see the similar thing. So suppose we are using let's say some kind of single sign on. Uh we put the username and password. Uh in this case we are also going to be asked by our SSO

provider to put the uh MFA as well. So I'm I'm putting my MFA and once I have put the MFA I'm logged in to my account and which is like as a as a normal user this is like you know simple scenario in Microsoft case what happened was this URL or the the the entire scenario was fished like they sent the wrong URL here user is going through the right URL they are logging in into their account and everything is going fine as a next step what as an attacker I'm going to do I'm going to set up a server I'm going to pause here. So I'm going to set up a server and I'm also going to

send a payload when the user clicks on it going to give me let's say the application has some level of local storage issue where whenever the user clicks on it the token will be grabbed from the storage and send it to me. So I'm sending this particular payload to the user and once the user clicks on it I have set up the poll server on the bub suite again. Um, and once the user clicks on it, we will see on the next screen, I keep on polling and I get the token here. Now, as an attacker, because this token can be used on any device, any machine, uh, just like a bearer token, right? Like anyone who who has

the token, they can spend it. So, I just put the token, replace it in my browser. Again, I don't have to go through the login flow. That's a very critical part. Once you have the token, you are not going through the login, MFA, anything. you just get the access to the user profile or whatever the information directly without doing anything. So MFA is not going to protect here what it will right. So most of us like thinks okay we have a pass key we have multiffactor authentication and it works but that's that's more like you know uh it works probably in the traditional system it works in the authentication but not in authorization. So with the bearer token the attacker

has the token passes the API server and access is granted. Now we need to introduce a new token called TPOP token which is demonstration proof of possession token. Uh I don't know if anyone knows about the anti-CSRF token which we probably use to protect against the CSRF kind of attacks. So this is somewhat similar. The only difference here is uh the depot token it has a key pair like a public key and a private key. Private key always stays on your on your laptop or your system and then public key is sort of like you know fingerprint into your into your token. So whenever client sends something to the API server it sends to the sends the

token and also some kind of a proof that they are the one who is accessing the token or accessing the API. So once the API validates the user validates the API key like public key matches to the private key then it will grant the access rather than anyone who has the token granting the access. Another mitigation probably you can think of which I have not added here uh which is probably you can lower the expiration of the bearer token. Usually what I've seen uh of all the application that I've been testing the barrier token validation is like you know either 6 hours 12 hours 20 hours etc. Right? So the the uh there's a lot of time for the

attacker to use this token grab the token use the token and extra extraate all the data. So maybe you can also think of as a developer when you're when you're creating the jot like how do you uh reduce the expiration of the token based on your uh based on your requirement. All right. Uh this one uh is the complex of all. Uh so this one is the federated identity confusion. Uh the third scenario. So here uh what we had is uh I'm sure like all of us are using more than one identity provider like all the application you go it has like login with Google, login with Microsoft, login with octa like multiple options uh they

always give you. So in this three options you can use any of the option and get access to your intended application and which is which is right like you you leave that to user which identity provider they want to use. The issue comes here is application usually like when you log in with Google and go to the application application only checks whether the token is correct or not. It does not check who issued it whether it was issued by the Google or Microsoft or octa or odd zero right it doesn't check that and that's the problem uh like you know attacker have usually been exploiting and this this this attack is widely applicable to like you know most of the

enterprise applications or enterprise environment I would say so most of the fed authentication system what it does is it checks the issuer of the token and and the subject right which is the user identity beyond that it doesn't check and and that's what like you know usually like you know even if you ask like claude or someone to write up the code for the authentication that's that's the default code which comes out now the issue will be here let's say you have Google authenticator uh sorry Google SSO which checks for which enforces the MFA uh which also makes sure that it checks against your uh active directory and make sure the user does exist while you have some

lower trust identity provider also as an option along with the Google SSO you're internally created and that gives you access to like you know same application but without multiffactor authentication maybe it also does not like you know enforce multiffactor it does not and it allows the self-registration and this was the real case in lot of enterprise application even though we don't realize sometime But if you if you go to the complex environment, you will see there are multiple uh providers and some providers you can self-register your accounts. So here uh just to switch the demo. All right. So here we have three uh identity provider. We have Google O YDC, we have Azure and then we have in in our environment we

have the internal IDP and which are usually used for the contractors. Now how the attack works is attacker can use any of these three IDP to log into the enterprise application. Right? So that's that's this is the scenario setup. Now let's go to the next page. And here let's say there is a there is a valid uh user called Sara and she is the admin of the like you know this application we call it as like you know uh internal application. So she clicks on the Google OIDC uh performs the authentication verifies the password uh it requires the MFA and Google issues the high insurance token then she uses the token to access the application and

that's that's how the system should work and everything works fine. Now let's say a contractor in the same company came in and he had a malicious behavior. Now the contractor says okay I'm going to use the internal IDP to use the same application. So what it's going to do it will try to create an account on the internal IDP using let's say the same email as the admin account which is admin@co company.com. Now this one this IDP as you probably see it does not enforce the MFA and it also allows the self-registration and in lot of the uh environments so for example like you know when I was working in Amazon as well we had a system where

contractors can have their own login and stuff but they use like you know slightly different system. So this is somewhat similar like in enterprises you would see there is a there is a way for provisioning the access to the contractors. Now once the attacker signs up with using the admin at company.com it creates the malicious account and the malicious account gets created on the IDP. The internal IDP allows this because there is no domain verification and there is no ownership verification. And there's no email verification and then there is no obviously MFA which which is not like you know too much critical for our scenario but anyway it does not do any of this validation and

the and the contractor has now access account on the internal IDP. Next thing attacker will do is it will sign in with the internal IDP. We'll put the email which is registered admin@co company.com and the password whatever it's set up mfo was not enforced so it can easily skip email verification was not required so that's skipped as well and then internal IDP issues the token now this token is still valid because it was still issued by one of the IDP which would allow you to access to our internal application so if we see in the next step all these secure like you know as a as a security engineer you would see these are all the

red flags but the application does not know because it just checks whether the token came from one of the IDP or not so here on the left hand side you could see what's the legitimate token looks like from the Google if it was issued from the Google however on the right hand side if you see this is the token issued by the internal IDP the token looks almost the same only the few checks are missing so once Once this token is issued, the token will be validated, it will issue the access and everything. So this is the if you have to go and look at the code as well. So this is the vulnerable code. So if you see the trust

issuance, it allows all three application. The application allows all three uh IDPS to access the application. And then also if you see here it's only checking the issuer and the subject. It does not check the trust level. And then finally it using the email as a identity. However, if you see the secure code it's much different. It's it does not allow you admin as an admin access. You want to have high trust IDP. Like if if you're using low trust IDP for your admin access that doesn't work. So you want to enforce you want to limit admin access should only be gone through the high trust IDP which is either Google Azure or something that like you know uh

has a more security granular controls and then after it also enforces the MFA because these are privilege access roles so you don't want a lower trust IDP to have access to it. After that uh of course the attacker takes the token from the lower IDP it try to access the application and everything works right there's nothing that uh application is going to work and this is how we actually had like you know compromise one of the enterprise application. Now let's talk about the mitigation part here. So uh in terms of securing the federated identity uh uh the first thing you we want to do is we want to use different IDPs. So maybe some IDPs have like you

know uh high trust and some has low trust. Maybe you can differentiate like if it's a contractor they can use one of the internal IDP but it can only limit access to non-admin user roles. Right? These are some of the checks that has to be built by the application developers because that's where the token will be validated. Then you can use the composite identity. What that means is you have to check for the issuer and subject and not the email. That means if you imagine the the admin@co company.com email was present in two identity providers. So these are not a single identity. If you use composite identity then this will be considered two separate identity

and this two separate identity will be treated differently. The third one is the IDP bound bound privileges. So admin access or any privilege access should only be granted through high privilege uh like you know high trusted IDPs. If if your application or your system or enterprise is using any internally developed IDPS that should not be allowed to grant access to the admin users and lastly claim validation. So verify the trustier uh account type MFA make sure email validations are happening if you are allowing self-registration to some of these uh identity providers. So all of this will will make sure that we are only limiting access to uh like you know the critical applications via uh our highress IDPS.

All right. Uh I think that's that's all I have. Uh thank you so much. I know it's a it's a last talk of the day. Uh I appreciate your commitment and dedication. Thank you so much.

And by the way, this is the QR code. If you trust me, you can scan it. That's my LinkedIn. But yeah, it it'll not take you to anywhere else. Yeah. >> Awesome. Thank you so much, Bik. We have a few questions. >> Mhm. >> How do you distribute deep tokens to public untrusted clients? >> Public untrusted clients. So there's not really like I wouldn't call it as untrusted clients. Uh if you are allowing access to the application uh either via registration or by invitation the the the clients are still like you know uh valid and they are signing up. They are they are authorized to access your application and the and we are not distributing the

token. Client generates the key pair. They can of course uh you can build this into the your client app maybe if you have mobile application it can still generate the key pair on the local device or the client like a browser uh can also generate the key pair via the front end code and store the private key or client can use their own private key as well. So it depends on which method uh like you know architecturally makes sense to you. uh but all of these method you can use uh to like generate the keys and the only thing is that the client has to pass is the public key when they when they try to request a token then

that's when the server will make sure the public key is there the password is correct the MFA is correct and it will be all binded into the token and then send it back to the client >> next question is if jots carry both identity and o data across oath and oidc flows Where's the weakest link? The token itself, the validation logic or the trust between servers? >> Um, from my perspective, the the weakest link going to be uh the validation. Uh, if you are talking about like you know uh different systems, if the jot is used by more than one system, then all system has to do the validation correctly. Uh so that that's the weakest link. Uh

another weakest link you could also say uh is like how the token is uh being like you know generated what the expiration of the token is. So that is also the weakest but yeah in the complex modern architecture uh it has to be how the token is validated. >> Awesome. Before I move on to the next question as a reminder you can post your questions to slido. You can go to bsidesf.org/q&a. The next question is if identity, authorization and trust all collapse into a single jot, are we securing systems or just protecting a very valuable string? >> Sorry, can you repeat that? >> Yeah. If identity, authorization, and trust all collapse into a single into a

signed jot, are we securing systems or are we just protecting a very valuable string? I think we are we are protecting the very valuable string. So u uh because when you combine everything into a single jot uh then of course uh the way you build the jot going to be very uh interesting and very challenging as well. Uh you want to make sure jotss are uh like you know following of course all the standard security practice which we saw in all the three scenarios. Uh following all the uh correct parameters correct attributes. So I think that that will be the uh key value there. >> Awesome. With that we are at the end of Q&A. Thank you so much Pomik for that

insightful and informational presentation.