Principal Consultant currently working for @mechanicalrock_. I'm also an AWS APN Partner Ambassador. AWS Certified x8.
I help teams get the most out of their cloud development experience.
It should be noted that there are two Authorization Code Flows
Authorization Code Grant Flow
Authorization Code With Proof Code Key Exchange (PKCE)
I'll assume you were referring to the former, because if the latter, I can say 'yes' and avoid an explanation.
The Authorization Code Grant Flow assumes you have some control over whatever is serving your content - because there is still an exchange of a client ID and secret from the calling client. You do not want store the client ID and secret in a Single Page Application, because then the client ID and secret would be exposed to the client.
There is a caveat here - this doesn't mean that you can't use Authorization Code Grant Flow for an SPA. You can! Provided you have control over whatever is serving the SPA content. E.g. if you were serving an Angular application via ASP.NET core, Flask, Express, etc, you totally could use the Code Grant Flow. You could even achieve it using CloudFront + S3 + Lambda@Edge.
BUT, if you are just serving web assets (HTML, images etc) straight from a bucket, with no capability to intercept web requests and perform some logic, you will not be able to use it - And this is typically how I've seen most SPA's hosted.
There was no real need in this post to stipulate any particular flow, but as the implicit flow has less moving parts, it was a bit easier to demonstrate the HTTP API JWT Authorizer functionality.
I should note though, that the implicit flow has been somewhat superseded by by Code Flow with PCKE. The link from Christian below does a good job of explaining the 'why' behind the PKCE flow.
Good question!
It should be noted that there are two Authorization Code Flows
I'll assume you were referring to the former, because if the latter, I can say 'yes' and avoid an explanation.
The Authorization Code Grant Flow assumes you have some control over whatever is serving your content - because there is still an exchange of a client ID and secret from the calling client. You do not want store the client ID and secret in a Single Page Application, because then the client ID and secret would be exposed to the client.
There is a caveat here - this doesn't mean that you can't use Authorization Code Grant Flow for an SPA. You can! Provided you have control over whatever is serving the SPA content. E.g. if you were serving an Angular application via ASP.NET core, Flask, Express, etc, you totally could use the Code Grant Flow. You could even achieve it using CloudFront + S3 + Lambda@Edge.
BUT, if you are just serving web assets (HTML, images etc) straight from a bucket, with no capability to intercept web requests and perform some logic, you will not be able to use it - And this is typically how I've seen most SPA's hosted.
There was no real need in this post to stipulate any particular flow, but as the implicit flow has less moving parts, it was a bit easier to demonstrate the HTTP API JWT Authorizer functionality.
I should note though, that the implicit flow has been somewhat superseded by by Code Flow with PCKE. The link from Christian below does a good job of explaining the 'why' behind the PKCE flow.
christianlydemann.com/implicit-flo...
auth0.com/docs/api-auth/which-oaut...