Here's how I would have posted the code sample for this question to make it easier to answer:

my $output = q/..../;
my $matched = $output =~ m/"access_token":"(.*)", "ex/g;
print "Match: $matched\n";
say '$1 is <', (defined($1) ? $1 : 'undef'), ">\n";
[download]

Except in place of .... I would paste in exactly the output from the curl call, but paired down to enough to demonstrate the portion you're trying to match without showing us 64kb of extra cruft.

When you do this, you will probably be able to answer the question yourself without even posting it, because you will see exactly why the match is failing.

But it's also probable that when you solve this problem, by retaining a regex approach you'll remain quite fragile. JSON isn't really intended to be processed as plain old text. And your regular expression is expecting the next key after "access_token" to start with "ex.

According to the JSON spec, "An object is an unordered set of name/value pairs." There's no guarantee of key order when objects are serialized and deserialized. That being the case, the match could fail while the data remains perfectly valid if you somehow got the keys back in a different order. There is no inherent order to hash keys, even in JSON. If you rely on an order, you're relying in an implementation detail that may work in practice but only works because nothing has changed to cause keys to come in some other order. Order is not guaranteed by the spec.

A far better approach would be to process the JSON as JSON using JSON to decode it. Then you could just dive into the datastructure precisely, and without any regex.