Jekyll2020-11-26T07:01:34+00:00https://joelsbraun.com/feed.xmlJoel BraunJoel BraunA More Definitive Guide to Mobile SSO2020-05-29T00:00:00+00:002020-05-29T00:00:00+00:00https://joelsbraun.com/2020/05/29/a-more-definitive-guide-to-mobile-sso<p>Lately I was a little frustrated with the lack of online resources which effectively describe how to effectively leverage session-based SSO on mobile platforms.</p>Joel BraunLately I was a little frustrated with the lack of online resources which effectively describe how to effectively leverage session-based SSO on mobile platforms.Why You Should Prefer OAuth Scope Validation Over Audience Validation2020-05-09T00:00:00+00:002020-05-09T00:00:00+00:00https://joelsbraun.com/2020/05/09/validating-oauth-audiences-and-scopes<p>I often receive the question of how OAuth token audience validation should work in environments where multiple OAuth clients are calling multiple resource services. Generally, the audience or <code class="language-plaintext highlighter-rouge">aud</code> claim in OAuth represents the application to which the OAuth token was issued. This can be handy as an additional layer of token validation for certain types of applications (say you have a single, monolithic application architecture with no additional services). However, validating the audience claim quickly starts to increase in complexity when multiple clients and services enter the mix.</p>
<p><img src="/assets/img/2020-05-09-validating-oauth-audiences-and-scopes/audience.svg" alt="audience validation" title="Audience validation diagram" /></p>
<p>As the number of applications in a service ecosystem scale, requiring audience validation forces all applications to track and validate against all audiences, often individual clients, which have been introduced. As new OAuth clients (with their new audiences) are created, this rapidly becomes an unwieldy task. One erroneous approach to correct this issue is to <a href="https://github.com/IdentityServer/IdentityServer3/issues/1365">try issuing multiple audiences in tokens</a>.</p>
<p>There’s a better alternative, which is to simply rely on scope validation. Rather than requiring each application accepting OAuth tokens to maintain knowledge of all possible clients, you can validate <code class="language-plaintext highlighter-rouge">scope</code> in a token instead. The <code class="language-plaintext highlighter-rouge">scope</code> array of values within a token represent the resources to which the token has access. This effectively inverts the dependency - rather than resources having to know what will call them, the IdP pre-determines which resources are allowed.</p>
<p><img src="/assets/img/2020-05-09-validating-oauth-audiences-and-scopes/scope.svg" alt="scope validation" title="Scope validation diagram" /></p>
<p>In practice, this proves to be a much better model as new client applications and resource services are added. Additionally, the list of scopes allowed for each client provides a effective form of ‘documentation’ for determining the resources upon which a particular client depends.</p>
<p>One of the common sources of this confusion is Microsoft’s own JWT authorization libraries, both for ASP.NET and ASP.NET Core. Rather than providing scope validation by default, they provide audience validation. <a href="https://github.com/IdentityServer/IdentityServer4.AccessTokenValidation/blob/master/src/AuthorizationPolicyExtensions.cs">A separate piece of middleware</a> is required to implement scope validation (but highly recommended!).</p>
<p>Interestingly, the <a href="https://tools.ietf.org/html/rfc6749">OAuth 2 Authorization Framework RFC</a> only mentions audience validation as a security mechanism for applications using less secure flows, such as implicit. All other references in the document use the term scope to describe the resource authorization property of an access token.</p>Joel BraunI often receive the question of how OAuth token audience validation should work in environments where multiple OAuth clients are calling multiple resource services. Generally, the audience or aud claim in OAuth represents the application to which the OAuth token was issued. This can be handy as an additional layer of token validation for certain types of applications (say you have a single, monolithic application architecture with no additional services). However, validating the audience claim quickly starts to increase in complexity when multiple clients and services enter the mix.The Summer of JavaScript2018-06-04T00:00:00+00:002018-06-04T00:00:00+00:00https://joelsbraun.com/2018/06/04/summer-of-javascript<p>Day to day, I work on the modern Microsoft stack - .NET Core, MSSQL, Linux/Docker, and building out both cloud and security initiatives at my organization. I love my place on the backend side of things, and typically don’t stray far from that area.</p>
<p>Ever so occasionally, it’s necessary to dip my toes into JS to finish some light frontend work. Javascript doesn’t have a strong reputation on my team (to put it mildly) despite its popularity. I’m curious to find out whether that reputation is well-founded.</p>
<p>Over the next couple of months, I’ll be immersing myself in the world of JS development, both frontend and backend. I’ve taken the time to update my newsfeeds to include information from some content experts and JS communities. I’ll try to take time and share some of my experiences and observations on this page as well.</p>
<p>Summer is always a good time to experiment a little with new technologies. The days are longer, so you have more time to troubleshoot the weird things you find. (I attribute the success of the long ago <em>Summer of Linux</em> to this.) My hope is that this one will prove just as informative and practically useful for me.</p>
<p><a href="https://www.youtube.com/watch?v=w5YI9ahUgnk&t=18s"><em>I proclaim this the “Summer of JavaScript”.</em></a></p>Joel BraunDay to day, I work on the modern Microsoft stack - .NET Core, MSSQL, Linux/Docker, and building out both cloud and security initiatives at my organization. I love my place on the backend side of things, and typically don’t stray far from that area.