woloski

things should be back to normal. Are you still seeing an issue?

It is great to see that the industry is moving from webhooks to Functions. We've seen this model succeed at Auth0 with our Rules feature [1] implemented 3 years ago. Recently productized this experience with Auth0 Extend [2]. It supports all node modules, a one-line of js emebeddable Editor, real time logs, vault to store secrets, custom programming models and crons.

[1] https://auth0.com/docs/rules

[2] https://auth0.com/extend/developers

The article is talking about webtask.io, the underlying engine for sandboxed code execution used by Auth0 for allowing customers to extend the platform with arbitrary nodejs code. In such system there is a need to acccess real time logs (think tail -f) while you are debugging your stuff.

Also, the emphasis is not just the real time aspect. The article mentions the issues with kafka for HA

Also looking for Technical Product Marketing Manager

hi sean, it's a hidden program :). We started this year with the first two interns and there is not much there on the site yet. If you are interested, [email protected]

Type of things you do as an intern (apart from eating Asado and live the city :) https://auth0.com/blog/2015/07/28/if-this-then-node-dot-js-e...

Auth0 https://auth0.com - Remote | Seattle, USA | Buenos Aires, AR

Auth0 makes identity simple for developers. Our subscriber base consists of more than 24,000 developers at over 20,000 enterprises across more than 150 countries around the world. We are growing quickly and well funded. https://auth0.com/blog/2015/06/23/another-big-milestone/

We are looking to expand our team in the following roles:

* Engineer (backend, frontend, ops)

* Product Designer

* Technical Writer

* Customer Success Engineer

See more at https://auth0.com/jobs

p.s. We also offer paid internships in Buenos Aires (flight, airbnb and salary)

Yep, you got it right. Re: holding the keys, response below. The encryption keys are on the server. We encourage you to deploy your own sharelock instance. We made that super easy with Herok. There is no storage, just a node app. And then you can configure the apps to use that Sharelock instance. More about it: https://github.com/auth0/sharelock#host-your-own-sharelock-s...

Read my response above.

The encryption keys are on the server. We encourage you to deploy your own sharelock instance. We made that super easy with Heroku for instance (https://dashboard.heroku.com/new?template=https%3A%2F%2Fgith...). There is no storage, just a node app. And then you can configure the apps to use the sharelock instance. More about it: https://github.com/auth0/sharelock#host-your-own-sharelock-s...

To start with, OAuth is an authoriation protocol and JWT is a token format (a signed and/or encrypted piece of data). So they are orthogonal.

The OAuth protocol doesn't specify which token format to use. Normally people have been using an "opaque" token, this is a token that doesn't have any meaning nor content but the meaning is stored somewhere. Here is an example of a table storing tokens and the scopes (permissions) associated to them. Every time an API Call is made, you would have to check against this table to see if the token sent in the Authorization header has the necessary scopes to call the API.

token | scopes oiajoeihfe9jh9283n | read.userinfo, post.friends uhuernvmiwmwo38h2g | read.userinfo

If you would use JWT you wouldn't have to store that information because it would be part of the token (i.e. stateless)

This would be a counterpart JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjM0NTY3O DkwLCJhdWQiOiJodHRwOi8vbXlhcGkiLCJzY29wZXMiOlsicmVhZC51c2VyaW5 mbyIsInBvc3QuZnJpZW5kcyJdfQ.tnLKyCWhVfkj2v15maCBJBVgPO08zFp2Lh n4Vkb4OoU

header: { "alg": "HS256", "typ": "JWT" }

payload: { "user_id": 1234567890, "aud": "http://myapi", "scopes": ["read.userinfo", "post.friends"] }

Google now changed their Authentication protocol to use OpenID Connect [1], which is a layer on top of OAuth plus a JSON Web Token. The thing about OpenID Connect which makes it useful for Authentication is that you can verify that the token (JWT) has been issued for your application (and not be used by another application) which was something the OAuth was lacking and a common vulnerability [2].

[1] https://developers.google.com/accounts/docs/OAuth2Login [2] http://homakov.blogspot.com.ar/2012/08/oauth2-one-accesstoke...

Thanks for spreading the word Adam!

We (Auth0) are heavy promoters of the usage of JWT. Here are some articles about using JWT instead of cookies on single page apps with APIs, and its pros/cons.

https://auth0.com/blog/2014/01/07/angularjs-authentication-w...

https://auth0.com/blog/2014/01/27/ten-things-you-should-know...

We wrote a blog post that shows how you can authenticate your users and get temporary security credentials from AWS based on the user tokens to avoid putting your keys on the client (both JavaScript apps in the browser or native apps). This technique is using Auth0 so you don't have to deploy a TVM and it works with all the APIs (S3, EC2, SQS, SES, etc.). Behind the scenes what we do is generating a SAML Token based on the user JSON Web Token and exchange that for AWS Temp Credentials using AssumeRoleWithSAML AWS API.

http://blog.auth0.com/2014/03/25/consume-aws-apis-from-the-b...

Yes, I don't think there is a one-size-fits-all answer. It will depend on your use cases. You can always start small using JWT and move to database backed tokens when you get a better idea of your architecture, use cases and authorization needs. For the user, it will still be opaque and bearer.

For images that are protected you can use this approach

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-...

Yes, that's correct.

Hey, Matias founder of Auth0 (https://www.auth0.com) here (we wrote the original article).

re: cookies vs xss. Expanding on sil3ntmac comment, based on my experience, it's easier to protect against XSS than protecting against CSRF. For CSRF you have to be aware of: set your cookies to HttpOnly and have a xsrf mechanism in place (which is not straightforward and not the default in many web frameworks, even worse if you start combining technologies). For XSS, you just need to make sure any input is sanitized, which usually most of the web frameworks provide something built-in.

Another interesting side effect of using JWT is that now you have a good cross-platform authentication mechanism that can cross boundaries. You can also achieve that with cookies, but you have to find the same implementation on different frameworks. We talk about this in this blog post about socket.io and json web tokens where it's very common to find PHP and node.js mixed.

http://blog.auth0.com/2014/01/15/auth-with-socket-io/

We will write follow up blog posts about pros/cons, because as usual there is no silver bullet.

I am curious, what were the drivers for this pricing instead of plain fixed price?

Yes, the link is there, maybe buried in all the text. Did you find the homepage too bloated? I added the open source bit in the initial statement

"MarkdownR is an open source project that provides collaborative realtime markdown editor built on top of share.js running on Windows Azure and node.js that allows..."

Glad you like it. Thanks for the bug, it's still work in progress. https://github.com/southworksinc/markdownR/issues/13