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! 😉

8 thoughts on “AAD B2C Quick Tips: query string parameters”

  1. That is brilliant.

    I run in another issue when I tried to get the “state” in the query string.

    It does work for any other query string name like “myQueryString=test” that you pass to B2C but if the query string is “state=thatIsMyState” it does not work.

    Any clue how could I achieve that?

    1. Hi Daniel!

      I also had an idea to use state parameter value, not only to pass some info back on user flow completion but also to read them inside of the policy. Sadly, no luck so far. I admit I haven’t been very thorough with my attempts but so far it didn’t work for me. I’m afraid that state, being an OAuth2 parameter, is treated differently and may not be resolved inside of policy. After all it is created by the client with purpose to be returned back to client (or any recipient responding on redirect URL).

      Those are guesses though. I’m not confident enough about it to suggest that it might be impossible to do.

  2. Wow, this is it. I also sunk +/- a full day into this seemingly simple task. There is lots of MS documentation around this, but it fails pretty hard at equipping the developer with a simple set of config changes to accomplish passing claims via URL query parameter. THANK YOU SO MUCH WOJTEK!

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.