Pure JavaScript (ES5.1) OAuth3 implementation for Browsers and Node.js
Go to file
AJ ONeal daf832cab5 cleanup 2017-02-08 04:27:36 -05:00
README.md add consideration of URI vs URL vs Pathname 2017-02-07 14:19:57 -05:00
oauth3.browser.js WIP refactor (refreshToken works) 2017-02-08 04:18:15 -05:00
oauth3.cache.js refactor browser-only code 2017-02-08 00:48:07 -05:00
oauth3.core.js WIP refactor (refreshToken works) 2017-02-08 04:18:15 -05:00
oauth3.jquery.js fix jQuery JSON POST/PUT/PATCH request, move lint to oauth3.lint.js 2017-02-06 20:10:31 -05:00
oauth3.js cleanup 2017-02-08 04:27:36 -05:00
oauth3.lint.js WIP refactor (refreshToken works) 2017-02-08 04:18:15 -05:00

README.md

oauth3.js

Public utilities for browser and node.js:

  • querystringify(query)
  • stringifyscope(scope)

URL generation:

  • authorizationCode
  • authorizationRedirect
  • implicitGrant
  • loginCode
  • resourceOwnerPassword

URI vs URL

See https://danielmiessler.com/study/url-uri/#gs.=MngfAk

Since we do not require the protocol to be specified, it is a URI

However, we do have a problem of disambiguation since a URI may look like a path:

  1. https://example.com/api/org.oauth3.provider
  2. example.com/api/org.oauth.provider/ (not unique)
  3. /api/org.oauth3.provider
  4. api/org.oauth3.provider (not unique)

Therefore anywhere a URI or a Path could be used, the URI must be a URL. We eliminate #2.

As a general rule I don't like rules that sometimes apply and sometimes don't, so I may need to rethink this. However, there are cases where including the protocol can be very ugly and confusing and we definitely need to allow relative paths.

A potential work-around would be to assume all paths are relative (elimitate #4 instead) and have the path always key off of the base URL - if oauth3 directives are to be found at https://example.com/username/.well-known/oauth3/directives.json then /api/whatever would refer to https://example.com/username/api/whatever.