401 (Unauthorized) when trying to call okta protected API from an angular app

[advii]

Hello,
I am using the sample app that I downloaded when I created the native app in okta console.

as I read in Use the access token | Okta Developer
I can use the access token to access the api. That’s my code:

val uri: Uri = Uri.parse("https://backend/tracks"

sessionClient?.run {
    authorizedRequest(uri,
        null,
        null,
        ConnectionParameters.RequestMethod.GET,
        object : RequestCallback<JSONObject, AuthorizationException?> {
            override fun onSuccess(result: JSONObject) {
                info_view.text = "it worked!!!"
            }

            override fun onError(
                error: String?,
                exception: AuthorizationException?
            ) {
                info_view.text = "it did not work!"
            }
        })
} 

I keep getting 401 (Unauthorized) error even though I am logged in with the same user I use for the okta app. What am I doing wrong?

[advii]

Do I need to set audience for the token somehow? how do I do it? I’m really at loss here.

[warren]

Does your resource server provide any logs? Also what does your issuer look like? Is it https://yourOrg.okta.com or https://yourOrg.okta.com/oauth2/default?

[advii]

I am the author of the service, it’s basically a plain spring boot service.

Not sure what you mean by issuer.
the app for the spring boot service looks like this:

APPLICATION

Application name

MyStravaStats

Application type

Web

Allowed grant types

Client acting on behalf of itself

Client Credentials

Client acting on behalf of a user

Authorization Code

Implicit (Hybrid)

Allow ID Token with implicit grant type

Allow Access Token with implicit grant type

## LOGIN

Login redirect URIs

http://localhost:8080/login/oauth2/code/okta
https://oidcdebugger.com/debug
http://localhost:4200/redirect
http://localhost:4200/implicit/callback
https://frontend-svc-dxfkonrad.cloud.okteto.net/login/oauth2/code/okta
https://frontend-svc-dxfkonrad.cloud.okteto.net/redirect
https://frontend-svc-dxfkonrad.cloud.okteto.net/implicit/callback
https://backend-svc-dxfkonrad.cloud.okteto.net/login/oauth2/code/okta

Logout redirect URIs

http://localhost:4200
https://frontend-svc-dxfkonrad.cloud.okteto.net/

Login initiated by

App Only

Initiate login URI

http://localhost:8080/login/oauth2/code/okta

[advii]

well it seems that when I send the authorized request the issuer is: https://dev-xxxxx.okta.com, but in my spring boot app it is https://dev-xxxx.okta.com/oauth2/default. could that be the problem?

[andrea]

Yup, that would do it. The token you send to your resource server should be using the Default Authorization server if that’s the authorization server your resource server is validating against. Sounds like you will need to update your Angular app to use the same issuer as the one your resource server is configured to use.

If you create a new token by calling https://dev-xxxxxx.okta.com/oauth2/default/v1/authorize instead of https://dev-xxxxxx.okta.com/oauth2/v1/authorize and send it to spring boot, do you still get a 401?

[advii]

Hi Andreas, thank you for answering.
However, funny enough, my json looks like this:

{
“end_session_redirect_uri”: “com.kb.mystravastatsandroidapp:/logout”,
“redirect_uri”: “com.kb.mystravastatsandroidapp:/login”,
“scopes”: [
“openid”,
“profile”,
“offline_access”
],
“issuer”: “https://dev-933944.okta.com/oauth2/default”,
“client_id”: “xxxxxxxxx”
}

the readme said also something about adding a config.json which I did and I also added this issuer there.
however, I still see the issuer as “https://dev-933944.okta.com/oauth2/default” in the providerConfiguration just before firing the request in SyncSessionClientImpl.createAuthorizedRequest.

so where does the wrong value come from? is it a bug? or maybe should I change the discoveryuri or org_URL and add the oauth2/default suffix?

Btw, I struggle to call the authorize endpoint from postman, getting an html file, maybe some parameters are wrong…

[andrea]

So your API/resource server and your front-end is configured to use the Default Authorization Server? And, yes, if you are referring to our okta-oidc-android library, you should make sure the discoveryUri includes /default in the path. Your mileage may vary with other libraries/SDKs, so double check the applicable reference doc to be sure you’re setting it as needed.

I’d be curious if you can find out if a manually generated token can be successfully used to access your API, because that at would likely point to a config issue on the native application.

The authorize call is usually handled through browser redirects, and that’s usually why one has trouble with it in Postman/curl. If you’re testing getting a token in Postman, you may want to check out this article that tells you how to find the authorization_code/token returned when you use the responseMode form_post.

[advii]

wow, Andreas, efharisto, when I already got an intense trauma with okta (again) you kind of initially saved the day, I changed the discovery url to oktadomain + oauth2/default and I see the data coming thru… now I only get a serialization error, I see the json data.

the error I’m getting is:

Value [{“trackId”:“1wA0XArOz9iG8-fDo_RPGO1yigJ69pUcY”,“fileName”:“Lange_Samstagsausfahrt.gpx”,“providerId”:“GDrive”},{“trackId”:“0BxqyEHf6g8vyMDZzUHhHMHFldWM”,“fileName”:“Indidishiminimal.gpx”,“providerId”:“GDrive”}] of type org.json.JSONArray cannot be converted to JSONObject

a quick remedy to that? I mean, it’s a perfectly valid use case that a REST API returns an array, no?
thank you in advance.
And again, is there an elegant replacement to the authorizedRequest method as it seems to be declared obsolete?

[andrea]

Ah, I’ve run into a limitation like this with authorizedRequest before.

As making external calls to an API are not part of the OIDC specifications, we determined that adding more flexibility to the authorizedRequest method (so that it can be used in more use cases) was out of scope for this SDK, and have made authorizedRequest obsolete accordingly. But like you said, totally reasonable that your API is returning a JSON array (many calls to Okta’s APIs do as well).

These days we suggest using Android’s HttpURLConnection or OkHttp so that you can set the parameters as needed, so you may want to check the sample code snippets we have in our guide for how to pass in your access token in your Authorization header.

[advii]

Hi Andreas,
sounds legit. I’ll test whether it works for me - thank you.
Thank you for your swift and competent help, btw I finally understood the concept of app, before I thought that one app has to cover all scenarios of access to a service which made me struggle a lot.