AAD B2C Quick Tips: query string parameters

Introduction

Maybe my idea or use case I came up with was weird and it’s my fault in general but I battled the problem of passing a parameter inside the AAD B2C policy for over a day with no progress at all.

I tried docs, StackOverflow, I’ve read all conversations in Azure Advisors which could give me a hint how to handle it, I cloned the AAD B2C Samples repository and searched it thoroughly.

I’ve applied every combination I found but still my policy was either throwing errors (some handled gracefully, some not) or it was utterly ignoring my efforts to make it do what I wanted it to do (doing nothing or passing the claim resolver ‘code’ as an actual value, completely unresolved)

The breakthrough was sudden and a bit unexpected as I was slowly starting to think there might be something fundamentally wrong with my tenant. I’ll leave my solution for your future reference, maybe it will save someone’s time.

Use scenario

I want to pass a value to the policy in a most simple of simplest ways – a query string parameter.
Why not JWT via id_token_hint? Two reasons:

  1. The query will be done by a public client so signing the token with a key stored in public app didn’t seem like having much sense
  2. PoC – I wanted to move fast by proving some general concepts and not go into too much implementation

Additional thing was I didn’t want to use it within RESTful provider (as I already did earlier – no problems, I got that working just fine) but to just retrieve the value from the URL and keep it inside the User Journey to do some checkups and pass it to other Technical Profiles along the User Journey way.

Solution

I prepared some really simple PoC UserJourney which consisted of a whopping number of three Orchestration Steps:

  1. Getting the value of the parameter
  2. Reading stuff from AAD (subject to Preconditions using the value from Step 1)
  3. Issuing a token

Looks easy. There is a claim resolver which I could use like this {oauth-kv:myCustomParameter} and which should give me a value of &myCustomParameter=myParameterValue query string parameter. Nice, except that it doesn’t or at least not in every place you imagine it would. And that caused a hellish operation of trying endless combinations based on statements, hints and half-suggestions found in all the sources I mentioned earlier.

In the end it turns out that it’s enough to do something like this:

(Obviously you need to declare myParameter claim schema before)

Now you just execute this Technical Profile on the very beginning of the UserJourney:

This makes the claim of your choosing available, filled with proper values and as usable as it would typically be:

Hope you’ll find that useful. Take care and B2C on! 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.