The Lazy Developer’s Guide to Authentication with Vue.js
This article shows you how to add authentication to a Vue.js application using the Okta Auth SDK and Okta API.
Yngvar Kristiansen
Storing access tokens in local storage is a security issue. https://dev.to/rdegges/plea…
Alfred Balle
Following the tutoral gives me 5 errors, all of them: https://google.com/#q=stand… Unexpected literal in error position of callback.
Ex. at src/auth.js:14:17.
Matt Raible
Hello Alfred: does this happen if you run the example app from GitHub? It’s possible you’re using newer versions of libraries that cause this issue.
Randall Degges
Hey Yngvar,
I’m the author of that dev.to post, and also work here at Okta. While storing stuff in localstorage is definitely bad, in some cases you cannot avoid it. For instance, let’s say you’re building a single page app with no server-side backend (like in this case). If you don’t have any sort of server-side backend at all, there’s no way you can generate a secure session cookie that can’t be accessed by JavaScript.
So while it is certainly true that this is less secure than a server-side counterpart, this is essentially the best type of security you can get for frontend-only apps!
Yngvar Kristiansen
Yeah, I agree. I hadn’t quite realized that when I posted my comment.
Anyway I think it’s important to highlight the risks related to XSS before one considers making a frontend-only app.
nikivancic
The problem is with the way callback is being used - (see https://github.com/oktadeve… as an example). At this point, the best solution for this problem is to add the rule ‘standard/no-callback-literal’: 0 to the file .eslintrc.js.
Posting this for future Vue / Okta users who will run into this - unless @mattraible decides to add this rule to https://github.com/oktadeve….
Philip Johnson
Thanks for this!
nikivancic
I am assuming that most people interested in this terrific sample (thank you Okta team who authored it) are creating a clone from https://github.com/okta/sam…. You would likely observe that ‘npm install’ results with several error messages - all of which could be addressed by running ‘npm audit’ followed by the npm suggested commands (like ‘npm install --save-dev url-loader@1.1.2’) that upgrade components found as security risks.
Matt Raible
Thanks for digging in and figuring this out! I’ll update this post this week and lock down the version numbers so it all works next time.
Matt Raible
Thanks for this advice! I updated the post today and included it.
nikivancic
@mattraible After 3 years of contribution to Aurelia project (https://aurelia.io/) I would like to do some work in Vue. Your sample might be a good start for me, so let me know if you would care for the Vue CLI 3 version. I think that this should be a separate project (rather than an update (PR)); you just created the VUE CLI 2.9.6, meaning that you care about maintaining the non-vue-cli-3 code).
If this is not world’s best proposal, would you care to work on a modern healthcare (patient centric) app instead?
nikivancic
@m@mattraible please check the issue “Removing vulnerabilities” at https://github.com/adriatic… which shows the steps I took to remove the vulnerabilities from your app as well as the resulting package.json.
Matt Raible
I forgot to merge the PR with the updated code. Sorry about that. It should be vulnerability free now. https://github.com/oktadeve…
Matt Raible
I’ll create a better example with Vue CLI 3. Stay tuned!
nikivancic
Being tuned 
nikivancic
Yes, the sample is free of vulnerabilities. Note that the skeleton application created by “vue init pwa okta-vue-auth-example” command has 18 vulnerabilities:
added 1497 packages from 1772 contributors and audited 11767 packages in 38.134s
found 18 vulnerabilities (10 low, 7 high, 1 critical)
I will report this to Vue team.
Paul Simon
Hi I tried this but I am getting a CORS error when I try to login.
Access to XMLHttpRequest at 'https://dev-XXXXXX.okta.com… from origin ‘http://localhost:8080’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Admitedly I have not tried this exact example as I was trying to incorporate this into existing code. I have checked that my settings in the OKTA API screen are as specified above. Is there any reason for this? My Vue App talks to a Node App and in the route there I effectively add the following to any request. However, as I cannot see a way to do the equivalent for the calls that are going out to OKTA.
res.header(“Access-Control-Allow-Origin”, “*”);
res.header(“Access-Control-Allow-Headers”, “Origin, X-Requested-With, Content-Type, Accept”);
I did have the login working from the basic Vue-OKTA guide on the OKTA site.
All that I really wanted to do was to get an event that I could intercept after the user logged in to get some credentials from them. Is there a way to do that?
Matt Raible
Hello Paul,
In your Okta app, you need to add “http://localhost:8080” as a trusted origin. You can do this by logging into your developer dashboard and going to API > Trusted Origins. FWIW, when you create an app, trusted origins are created for you automatically based on your redirect URIs. If you modify them after creating your app, they are NOT added as trusted origins.
Paul Simon
Hi Matt, Thanks for your reply but I already had that in place, so I am not sure what the problem was…However, with some help from OKTA Support I went about it a different way. I left the standard approach from the intro to Vue on OKTA in place, and just took a copy of the implicitcallback.vue file from the node_modules, Copied it to my src folder renamed it and then amended it to carry out the extra operation that I needed after a successful login,
export default
{
name: ‘OKTAPostLogin’,
async beforeMount ()
{
await this.$auth.handleAuthentication()
// Start of our code
this.OurRoutine()
// End of our code
this.$router.replace(
{
path: this.$auth.getFromUri()
}
)
},
render()
{
},
So effective we put out code to get information on the user from the database, after the handleAuthentication has confirmed that the user has logged in successfully and has stored the tokens, and before OKTA redirects back to the original route that the user was trying to access before OKTA popped up the login challenge.
Regards
Paul Simon