Generating JWT Token for Apple API Requests

Question

Has anyone successfully generated a valid token for Apple's App Store API using ColdFusion?We are following the instructions from Apple and cannot get the damn thing to authenticate. Every call returns "401 Unauthorized ". We're using a JWT CFC code found here the uses Java for signing the JWT. The curious thing is, we've used this same CFC to successfully sign a JWT (slightly different payload) for use with Apple's MapKitJS API. But, for reasons unknown, we can't get the App Store API to authenticate. Any help is appreciated. Our code sample: -----BEGIN PRIVATE KEY----- Our Key Data Here -----END PRIVATE KEY----- "

sdsinc_pmascari · Accepted Answer

Ah, well, would you agree then that until you can get it working from postman, there's no reason to bang your head against the wall trying to run it from cf? 🙂

Maybe you mean you hoped it might work from cf despite not working from postman...or that the cfc might have helped...or that someone here had done it.

Since those are not panning out, and while your searches otherwise have not, you may have better luck asking in still other cfml forums where it may well BE that someone there has already blazed this trail (but just not blogged about it).

Try the cfml slack, the Facebook cf programmers group, and even the lucee dev group. I offer links to these in a category of my cf411.com site, specifically https://www.cf411.com/cfhelp.

I appreciate that you may have already know of or perhaps even had tried these. I couldn't know. I share this also for others who may find it.

I'd look forward to seeing how things turnout.

OMG! I figured it out!

First off - the main issue was the 'exp' and 'iat' values do need to be INT

The problem was the jwt.cfc was converting my dates to strings. So, instead of passing CF dates into the CFC, I converted them to epoch time using an old 'epoch' function I had laying around:

<cfset tokenPayload = {
		"iss":"my-iss-code",
		"iat":int(epochTime(now())),
		"exp":int(epochTime(dateAdd("n",20,now()))),
		"aud":"appstoreconnect-v1",
		"bid":"com.my.app"
	}>

<cffunction name="epochTime" output="No">
	<cfargument name="dt" required="false">

	<cfreturn DateDiff("s", "January 1 1970 00:00", isDefined("arguments.dt") AND isDate(arguments.dt)?arguments.dt:now())>
</cffunction>

However, this still didn't work: 401 Unauthorized.

But then I noticed something when I tried pasting my token to jwt.io:

The time portion of my Epoch code was 4 hours ago! So, the expiration had long passed! WTF?

SOLUTION:

So, I removed my epochtime() function and, instead, made a simple change in the jwt.cfc script using the int() function to make sure the converted time is an INT:

Payload:

<cfset tokenPayload = {
		"iss":"my-iss-code",
		"iat":now(),
		"exp":dateAdd("n",20,now())),
		"aud":"appstoreconnect-v1",
		"bid":"com.my.app"
	}>

Portion of jwt.cfc making sure the converted date is INT:

var duplicatedPayload = duplicate( payload );
        for ( var claim in [ 'iat', 'exp', 'nbf' ] ) {
            if ( duplicatedPayload.keyExists( claim ) && isDate( duplicatedPayload[ claim ] ) ) {
                duplicatedPayload[ claim ] = int(encodingUtils.convertDateToUnixTimestamp( duplicatedPayload[ claim ] ));
            }
        }

Charlie Arehart · Answer

Paul, in a case like this (where mapping the api doc info to a cf request still fails for a reason not made clear in the error), I'd argue the best next step is to set up postman to make the call. On confirming it works, then modify the cfhttp code to ensure you send EXACTLY what postman sends: down to even every header and value.

(And be sure to run postman ON the server/machine that is running cf, as a sanity check. You may find that even postman could get a 401 there, though I'd expect it will not.)

Once you have the cfhttp working, you could try taking things away that may not have been needed (various headers, for instance).

You may also want to to try using in postman whatever result you got from the cfc. You may find it doesn't work, and that's your problem. (Then you can reconcile what DOES work between that result and whatever original value you created manually using postman, in the first working case.)

Yes, it would be nice if somehow it all "just worked". Sometimes it's a lack in the apidocs. Sometimes it's a mistake in what you're trying. And sometimes it's just that you're blazing a trail and are the first to discuss your attempt, so the breadcrumbs you leave are what will help the next person succeed more easily.

Sadly there's no doc or example repo showing cf working with the many various APIs. It would be a cool idea, though also a challenge to keep updated, as APIs evolve, old versions get deprecated, etc.

Hope the info above may help get you to at least a working example.

Cadastre-se

Fazer o login com rede social

Bem-vindo

Fazer o login com rede social

Verificando arquivo em busca de vírus

Este arquivo não pode ser baixado