Null Pointer Exception when creating Tokens with Implicit Grant Type

[anonymous]

I’m receiving the Following error when trying to create a token the Implicit Grant type

Error 500 : Internal Server Error

Time: 357ms

Size: 256 B

{
    "fault": {
        "faultstring": "NullPointerException",
        "detail": {
            "errorcode": "Internal Server Error"
        }
    }
}

What I was doing is the ff.
https://community.apigee.com/questions/70503/how-can-i-have-multiple-callback-urls-in-an-app.html?childToView=70545#comment-70545

I could already do that and issue Authorization Code dynamically.

I’m using the very same policy in creating those authorization codes for extracting the redirect_uri with my policy for implicit grant type token creation. And I could very well see that those policies are executed properly as it returns a value and append the the redirection_uri to the initial request parameters. My only issue is whenever it reaches the implicit grant type policy of token generation is that it throws an error of “Execution Error” on the policy for “GenerateAccessTokenImplicitGrant”. And I don’t know why and where it’s getting a null value anywhere. How do I solve this?. TIA

BTW. The following is my policy for generating a token of implicit grant.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="GenerateAccessTokenImplicit">
    <DisplayName>GenerateAccessTokenImplicit</DisplayName>
    <Operation>GenerateAccessTokenImplicitGrant</Operation>
    <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
    <GenerateResponse/>
</OAuthV2>

[anonymous]

My Trace Log is here

https://drive.google.com/file/d/1xVaxF6lnLbbOAUPoQT8jKzJzeIKXAOo8/view?usp=sharing

[anonymous]

try to debug it with and <GenerateErrorResponseenabled=‘true’/> to see the more detailed error. and how you are passing implicit grant type in the request also matters. Please add moock proxy to help you further.

[dchiesa1]

First, unrelated to Apigee Edge, the current “best current practices” for OAuth2.0 suggest that you don’t use Implicit Grant, ever.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.1.2

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 4.1, Section 4.2,
   Section 4.3, Section 4.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 3.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token")...

This is unrelated to any Apigee Edge implementation. The Implicit Grant is still supported within the Apigee Edge OAuth2.0 policies (for granting tokens and verifying tokens), but the internet standards bodies recommend against it.

Now, as to your specific problem, I’m sorry you’re experiencing this problem. It’s really lame that there’s such an unhelpful error message. “Null pointer exception” is not giving you anything useful.

Maybe I can help and give some hints. to get started, can you please share your policy? And also a view of your policy flow. (what policies come BEFORE the GenerateAccessToken policy?) If you can share your entire API proxy, I’d like to look at it.

As a first tip, you may need to set the client_secret, even if you prefer to not require the client to pass it. To do that in the policy flow, you may need to use an AccessEntity policy to retrieve it based on the passed client_id. That’s the first thing I would try.

In the meantime I’ll look for a working example of an implicit grant flow, to maybe help you get started.

[anonymous]

Hi @Dino-at-Google , thanks for the reply.

For the background of what I’m doing. See below…

We don’t actually need the implicit grant flow in our process to authenticate the user as we are only required to use PKCE,but since we need to cache the initial parameters sent on first request, we are just using it (implicit grant created token) for caching multiple attributes that we are going to use for the actual athentication we have which is OAuth PKCE. We are saving the temporary attributes like code , code_challenge/sessionID etc to the token for a few minutes, after which this token will then be used to authenticate if it has access to our login server.

It just that before issuance of Authorization Code, we still have this Login and OTP process in the middle hence we have to cache the initial parameters we sent with the use of a token which could easily be saved and retrieve by creating a token and associating details to it, and at the same time, authenticate if the user has access to our login endpoint. After Login and OTP, the same token will then be used to authenticate whether if the user has acquired a token that is allowed to use our endpoint (based on the scope it has )which issues an authorization code. The attributes stored in this token will then be retrieved and passed when creating an authorization code like code_challenge, challenge_method etc that will then ind it to the authorization code for it to be used when creating the token that was created with the OAuth - PKCE requirements.

Is that a good practice?. I am doing this caching in the token as this is a recommendation from my previous question from here.

https://community.apigee.com/questions/70394/how-to-add-attributes-to-a-cache.html

BTW, I included in this comment my API Proxy.

initiateauthorize-rev16-2019-07-16.zip

GDrive Link:
https://drive.google.com/file/d/1IoPetRlLcJ9L9QVaWkS0OwmC9u4pwwyd/view?usp=sharing

I’m using the ff. request that is throwing an NPE.

/pkce/authorize?response_type=token&client_id=[insertAValidClientIDHere]&scope=all&code_challenge=sampleCodeChallengeIsHere&code_challenge_method=S256&BillerCode=54321&UserId=GoogleApigeeEdge

What I found rather odd about this NPE error is that whenever I manually add the redirect_uri in the initial request, is that it works properly . So if you try this request instead, is that it works.(So my Generate TOken policy for implicit grant is working). But I now I have two redirect_uri in my request parameters right after my Assign message policy. One if which is automatically retrieved from the Apps custom attribute.

/pkce/authorize?response_type=token&client_id=[insertAValidClientIDHere]&scope=all&code_challenge=sampleCodeChallengeIsHere&code_challenge_method=S256&BillerCode=54321&UserId=GoogleApigeeEdge&redirect_uri=www.google.com

[anonymous]

I just added

<GenerateErrorResponseenabled='true'/> 

to my Generate Token Policy. However, I’m seeing the same vague error.

BTW. Manually adding the redirect_uri on my initial request works. So my Generate TOken Policy certainly works. But my automatic creation of Redirect URI that is saved in the app is working though as it’s returning true and appending the proper parameter and actual redirect_uri i want as what I could see in the trace log. However, its throwing an NPE, and I don’t know where it is getting that NPE.

[dchiesa1]

hi, I had a nice long reply typed in, and it vaporized. Ooops!

Let me try to restore it.

It sounds to me that you are using the token generated via Implicit Grant as a way to track state internally. If this is the case, if the client never receives this token, then… I would suggest that you can use a better mechanism. PopulateCache may be what you want - just store a JSON payload into the cache. You can generate a random cache key and use that key to later be able to retrieve the state.

Unfortunately I cannot download the proxy you seem to have attached. When I click the link I get a 404. But in any case you can avoid the issue around implicit grant NPE by not using GenerateAccessTokenImplicitGrant, maybe instead using PopulateCache and GenerateAuthorizationCode.

---

So if you try this request instead, is that it works.(So my Generate TOken policy for implicit grant is working). But I now I have two redirect_uri in my request parameters right after my Assign message policy. One if which is automatically retrieved from the Apps custom attribute.

It sounds to me that if you pass redirect_uri as a query param, then the policy does not generate a NPE.

Why are you not simply doing that? Pass the query param.

But in any case you can avoid this by using PopulateCache and GenerateAuthorizationCode.

[anonymous]

Hi @Dino-at-Google, I updated the attachment and even included a Google Drive link just in case. The Proxy should be downloadable by now.

https://drive.google.com/file/d/1IoPetRlLcJ9L9QVaWkS0OwmC9u4pwwyd/view?usp=sharing

[dchiesa1]

IF YOU CONTINUE with the Implicit Grant hack, I think you want Set and not Add in the AssignMessage.

<AssignMessage name="AM-FirstRedirect">
    <Set>
        <QueryParams>
            <QueryParam name="redirect_uri">{redirect_uri}</QueryParam>
        </QueryParams>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

But I’m not clear on whether you want this ^ policy or not. I can’t be sure whether you want to apply the query param in the policies or you want to require the inbound request to include a redirect_uri.

Again, my advice is to not use an Implicit Grant token, at all, ever. In other words: don’t do it.

Use PopulateCache or some other state storage mechanism. Don’t use implicit grant tokens for storing state temporarily.

[anonymous]

Hi @Dino-at-Google, there seems to be a problem with Apigee Edge. As everything like this redirect_uri, and now client_id is not being detected by Edge even though though I could very well see in the trace that it is being appended in the flow.