Has anyone had any luck implementing Okta with EmberJS?
I thought about writing a Torii provider but wasn’t sure if that was the best approach.
Would I be better off trying to implement a the sign-in widget?
Any direction would be extremely helpful…
You can totally use the SignIn Widget. I have not messed with EmberJS and our API, but you should be able to use the widget for sign in and using the API to do more complicated stuff (Creating users, etc).
Yeah it was a lot easier than I expected to hook in the sign in widget 
One question I have is how should I handle authentication with my backend server if I use with sign in widget? Would I just send the token to the backend that is received back from the widget and then validate it?
Just a note, you should always send the access_token to your backend, not the id_token. That is the general flow, what backend are you using?
1 Like
Yeah of course
I’m using Spring Cloud, with the Okta spring starter package.
I’m almost there, just still slightly confused on the flow/concepts a tad…
I have the sign in widget hooked into Ember, and I’m taking the access_token returned from Okta and sending that to my backend server.
Do I now using the Okta Java library validate the access token and return an id_token to the frontend? If that’s the case do I just throw away the id_token sent to me from the sign in widget? That seems a bit of a pointless exercise?
Or is the idea that I can send the access token to my backend server, confirm it is correct via the Java SDK, and then return a Principal user to the frontend client?
Sorry if these seem like silly questions, first time trying to really setup anything other than simple social logins.
1 Like
On your backend, you can use our Spring Boot starter to protect your API and validate tokens. As far as returning a Principal to the front end, that’s an option. But you can also use the id_token since that has a lot of the user’s information in it.
Thanks for the response, I’m currently using the Okta Spring Boot starter, and implementing as per the example in the siw-jquery package.
I’m sending my server the response from the Sign in widget which looks like this
{"accessToken":"eyJhbGciO...****","expiresAt":1509399778,"tokenType":"Bearer","scopes":["openid","email"],"authorizeUrl":"https://dev-****.oktapreview.com/oauth2/default/v1/authorize","userinfoUrl":"https://dev-****.oktapreview.com/oauth2/default/v1/userinfo"}
But I’m still getting unauthenticated when trying to request my API, I assume the ResourceSecurityConfigurer class is handling dealing with the incoming token?
There is a lot of different blogs/tutorials for Okta with Spring but it’s hard to understand which one I should be following.
You should send just the access token to your API. It should be in a header named “Authentication” and be prefixed with "Bearer ". Here’s an TypeScript example from one of the Angular tutorials I wrote.
const accessToken = this.oktaService.signIn.tokenManager.get('accessToken');
request = request.clone({
setHeaders: {
Authorization: `${accessToken.tokenType} ${accessToken.accessToken}`
}
});
I’ve got that part covered, but that’s ahead of where I am at the moment.
I’ve just gotten the response from the Widget, I need to send that as a REST request to my backend to return a JWT or something (I’m not sure yet) to the client to complete the authentication process for Ember (using ember-simple-auth).
@PostMapping("/auth/login")
public Response authResponse(@RequestBody String oktaResponse) {
// Do something with data from sign in widget
return Response.status(Response.Status.OK).entity("Something Here").build();
}
Then all following calls will be handled with Authorization Bearer headers;
I guess it’s just the actual login with the backend service is where I’m stuck.
1 Like
If you’re using the Okta Spring Boot Starter, you don’t need to post anything to your backend to authenticate. Sending the Bearer token is all you’ll need to access your endpoints.
I haven’t used ember-simple-auth, but I noticed it does have OAuth 2.0 support, so you might be able to use that (with Okta) instead of our SDKs.
1 Like
You’re correct, the ember authenticator tripped me a little as I thought I had to send it off to my backend but I can actually just do
authenticate(oktaResponse) {
return new RSVP.Promise((resolve) => {
resolve({
token: oktaResponse,
});
});
},
So my authorizer now has the token set in the header for each request.
Thanks again mraible, your blog posts have also been extremely helpful in figuring all this out.
2 Likes
Sweet! Glad you got it working. If you happen to write a blog post about integrating Ember with Okta, please let me know. We’d love to send you some traffic.
1 Like
My last little hurdle to success… When copying the access token returned from the Okta Widget and using Postman to send a request, I’m getting invalid_token back from my backend.
{
“error”: “invalid_token”,
“error_description”: “Invalid access token: eyJhbGciOiJSUzI1NiIsImtpZ****”
}
Does this mean something isn’t setup properly with my Okta Widget and it’s creating a bad token?
const oktaSignIn = new OktaSignIn({
baseUrl: 'https://dev-****.oktapreview.com',
redirectUri: 'http://localhost:4200/instances',
clientId: '****',
authParams: {
issuer: 'https://dev-*****.oktapreview.com/oauth2/default',
responseType: ['token']
}
});Do you have the following configured on your server?
okta:
oauth2:
clientId: ****
issuer: https://dev-****.oktapreview.com/oauth2/default
From: https://developer.okta.com/blog/2017/10/27/secure-spa-spring-boot-oauth
I do, but I have it in my bootstrap.yml file rather than my application.yml file… I’m not sure if this would make a difference?
I’d give it a try in application.yml and see if that helps.
Unfortunately the app fails to boot when I move it to application.yml
I get ERROR org.springframework.boot.SpringApplication - Application startup failed java.lang.IllegalArgumentException: issuer cannot be empty
Thrown from the com.okta.spring.oauth.discovery package.
For sanity, my complete application.yml file:
spring:
application:
name: edge-service
server:
port: 8080
logging:
level:
root: INFO
org.springframework.web: INFO
org.springframework.security: DEBUG
security:
oauth2:
resource:
userInfoUri: https://dev-****.oktapreview.com/oauth2/default/v1/userinfo
okta:
oauth2:
clientId: ****
issuer: https://dev-****.oktapreview.com/oauth2/default
I am however now receiving Access is denied (user is anonymous); redirecting to authentication entry point rather than invalid token, so progress I suppose.
Sorry for all the spam… Looks like my issue is to do with the fact I was trying to authenticate endpoints on a Zuul Proxy enabled host. When I move all the authentication to the actual services things work as expected (well, for the moment when skipping the proxy).
I guess Zuul handles incoming requests a little different and is something I’ll need to investigate further. mraible I have seen your post from August around this, any chance of an updated version? 
It wasn’t too difficult to support Zuul in the Stormpath SDK, we should be able to add it to Okta’s. Or maybe we should just skip to Spring Cloud Gateway? https://github.com/spring-cloud/spring-cloud-gateway