Using API-Key in Vapor
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I'm developing a simple web API with Vapor. To give more context, I'm newbie in backend development.
The consumer of the API is going to be an iOS app. Currently, I don't need the users to sign up to use the app. And I would like to keep it like that.
On the other hand, I would like to have some authentication to avoid that anyone could use the API I'm developing.
Looking for information I've found how implement authentication. But the examples I've seen are based on creating users in the backend for each user of the app. What I don't want to do. I would like to use an api-key as we do normally when we use third-party api's.
How could I have "api-key authentication" with Vapor ??
Or, should I just create an unique user/password that it's shared by all the users of the iOS app (that use the API) and then use basic or token authentication?
Thank you very much!
Carlos
vapor
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
add a comment |
I'm developing a simple web API with Vapor. To give more context, I'm newbie in backend development.
The consumer of the API is going to be an iOS app. Currently, I don't need the users to sign up to use the app. And I would like to keep it like that.
On the other hand, I would like to have some authentication to avoid that anyone could use the API I'm developing.
Looking for information I've found how implement authentication. But the examples I've seen are based on creating users in the backend for each user of the app. What I don't want to do. I would like to use an api-key as we do normally when we use third-party api's.
How could I have "api-key authentication" with Vapor ??
Or, should I just create an unique user/password that it's shared by all the users of the iOS app (that use the API) and then use basic or token authentication?
Thank you very much!
Carlos
vapor
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
add a comment |
I'm developing a simple web API with Vapor. To give more context, I'm newbie in backend development.
The consumer of the API is going to be an iOS app. Currently, I don't need the users to sign up to use the app. And I would like to keep it like that.
On the other hand, I would like to have some authentication to avoid that anyone could use the API I'm developing.
Looking for information I've found how implement authentication. But the examples I've seen are based on creating users in the backend for each user of the app. What I don't want to do. I would like to use an api-key as we do normally when we use third-party api's.
How could I have "api-key authentication" with Vapor ??
Or, should I just create an unique user/password that it's shared by all the users of the iOS app (that use the API) and then use basic or token authentication?
Thank you very much!
Carlos
vapor
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
I'm developing a simple web API with Vapor. To give more context, I'm newbie in backend development.
The consumer of the API is going to be an iOS app. Currently, I don't need the users to sign up to use the app. And I would like to keep it like that.
On the other hand, I would like to have some authentication to avoid that anyone could use the API I'm developing.
Looking for information I've found how implement authentication. But the examples I've seen are based on creating users in the backend for each user of the app. What I don't want to do. I would like to use an api-key as we do normally when we use third-party api's.
How could I have "api-key authentication" with Vapor ??
Or, should I just create an unique user/password that it's shared by all the users of the iOS app (that use the API) and then use basic or token authentication?
Thank you very much!
Carlos
vapor
vapor
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
asked Nov 23 '18 at 23:38
CarlosCarlos
612923
612923
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
One way around this is to create a fake token and use either the TokenAuthenticationMiddleware or more likely a custom middleware that checks the incoming token.
However, be aware that there is nothing stopping anyone from inspecting the traffic coming from your app to view the token and then using that to access your API.
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
add a comment |
Following Tim idea and an example from the book Server Side with Vapor (by the Raywenderlich.com Tutorial Team) I've created this custom middleware that makes the work:
final class SecretMiddleware: Middleware {
let secret: String
init(secret: String) {
self.secret = secret
}
func respond(to request: Request, chainingTo next: Responder) throws -> Future<Response> {
guard let bearerAuthorization = request.http.headers.bearerAuthorization else {
throw Abort(.unauthorized, reason: "Missing token")
}
guard bearerAuthorization.token == secret else {
throw Abort(.unauthorized, reason: "Wrong token")
}
return try next.respond(to: request)
}
}
extension SecretMiddleware: ServiceType {
static func makeService(for worker: Container) throws -> SecretMiddleware {
let secret: String
switch worker.environment {
case .development:
secret = "foo"
default:
guard let envSecret = Environment.get("SECRET") else {
let reason = "No SECRET set on environment."
throw Abort(.internalServerError, reason: reason)
}
secret = envSecret
}
return SecretMiddleware(secret: secret)
}
}
answered Jan 20 at 19:18
CarlosCarlos
612923
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53453913%2fusing-api-key-in-vapor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
One way around this is to create a fake token and use either the TokenAuthenticationMiddleware or more likely a custom middleware that checks the incoming token.
However, be aware that there is nothing stopping anyone from inspecting the traffic coming from your app to view the token and then using that to access your API.
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
add a comment |
One way around this is to create a fake token and use either the TokenAuthenticationMiddleware or more likely a custom middleware that checks the incoming token.
However, be aware that there is nothing stopping anyone from inspecting the traffic coming from your app to view the token and then using that to access your API.
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
add a comment |
One way around this is to create a fake token and use either the TokenAuthenticationMiddleware or more likely a custom middleware that checks the incoming token.
However, be aware that there is nothing stopping anyone from inspecting the traffic coming from your app to view the token and then using that to access your API.
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
One way around this is to create a fake token and use either the TokenAuthenticationMiddleware or more likely a custom middleware that checks the incoming token.
However, be aware that there is nothing stopping anyone from inspecting the traffic coming from your app to view the token and then using that to access your API.
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
answered Nov 24 '18 at 19:18
0xTim0xTim
1,006512
1,006512
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
add a comment |
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Agreed, only thing that would mitigate downside of inspecting traffic is using cert pinning. But I doubt this application calls for that level of security.
– Andrew Edwards
Nov 24 '18 at 20:10
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Thanks Tim! One question (maybe silly). About someone inspecting the traffic coming from my app. I would have this problem always, right? I mean, even if I implemented full authentication, someone could inspect the traffic and get the token of an specific user, couldn't they?
– Carlos
Nov 25 '18 at 14:19
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
Yeah cert pinning is one way around it, but you can still decompile the app and pull out the key. There are barriers you can put up but it’s essentially impossible to completely stop it.
– 0xTim
Nov 25 '18 at 21:23
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
@Carlos yeah you’d always have the issue. However with full authentication then you require users to provide credentials to get a key. That means you can lock it down better. For instance you don’t have a global key that can do everything, you can add authorisation so that API key can interact with only certain parts. Does that make sense?
– 0xTim
Nov 25 '18 at 21:26
add a comment |
Following Tim idea and an example from the book Server Side with Vapor (by the Raywenderlich.com Tutorial Team) I've created this custom middleware that makes the work:
final class SecretMiddleware: Middleware {
let secret: String
init(secret: String) {
self.secret = secret
}
func respond(to request: Request, chainingTo next: Responder) throws -> Future<Response> {
guard let bearerAuthorization = request.http.headers.bearerAuthorization else {
throw Abort(.unauthorized, reason: "Missing token")
}
guard bearerAuthorization.token == secret else {
throw Abort(.unauthorized, reason: "Wrong token")
}
return try next.respond(to: request)
}
}
extension SecretMiddleware: ServiceType {
static func makeService(for worker: Container) throws -> SecretMiddleware {
let secret: String
switch worker.environment {
case .development:
secret = "foo"
default:
guard let envSecret = Environment.get("SECRET") else {
let reason = "No SECRET set on environment."
throw Abort(.internalServerError, reason: reason)
}
secret = envSecret
}
return SecretMiddleware(secret: secret)
}
}
answered Jan 20 at 19:18
CarlosCarlos
612923
add a comment |
Following Tim idea and an example from the book Server Side with Vapor (by the Raywenderlich.com Tutorial Team) I've created this custom middleware that makes the work:
final class SecretMiddleware: Middleware {
let secret: String
init(secret: String) {
self.secret = secret
}
func respond(to request: Request, chainingTo next: Responder) throws -> Future<Response> {
guard let bearerAuthorization = request.http.headers.bearerAuthorization else {
throw Abort(.unauthorized, reason: "Missing token")
}
guard bearerAuthorization.token == secret else {
throw Abort(.unauthorized, reason: "Wrong token")
}
return try next.respond(to: request)
}
}
extension SecretMiddleware: ServiceType {
static func makeService(for worker: Container) throws -> SecretMiddleware {
let secret: String
switch worker.environment {
case .development:
secret = "foo"
default:
guard let envSecret = Environment.get("SECRET") else {
let reason = "No SECRET set on environment."
throw Abort(.internalServerError, reason: reason)
}
secret = envSecret
}
return SecretMiddleware(secret: secret)
}
}
answered Jan 20 at 19:18
CarlosCarlos
612923
add a comment |
Following Tim idea and an example from the book Server Side with Vapor (by the Raywenderlich.com Tutorial Team) I've created this custom middleware that makes the work:
final class SecretMiddleware: Middleware {
let secret: String
init(secret: String) {
self.secret = secret
}
func respond(to request: Request, chainingTo next: Responder) throws -> Future<Response> {
guard let bearerAuthorization = request.http.headers.bearerAuthorization else {
throw Abort(.unauthorized, reason: "Missing token")
}
guard bearerAuthorization.token == secret else {
throw Abort(.unauthorized, reason: "Wrong token")
}
return try next.respond(to: request)
}
}
extension SecretMiddleware: ServiceType {
static func makeService(for worker: Container) throws -> SecretMiddleware {
let secret: String
switch worker.environment {
case .development:
secret = "foo"
default:
guard let envSecret = Environment.get("SECRET") else {
let reason = "No SECRET set on environment."
throw Abort(.internalServerError, reason: reason)
}
secret = envSecret
}
return SecretMiddleware(secret: secret)
}
}
answered Jan 20 at 19:18
CarlosCarlos
612923
Following Tim idea and an example from the book Server Side with Vapor (by the Raywenderlich.com Tutorial Team) I've created this custom middleware that makes the work:
final class SecretMiddleware: Middleware {
let secret: String
init(secret: String) {
self.secret = secret
}
func respond(to request: Request, chainingTo next: Responder) throws -> Future<Response> {
guard let bearerAuthorization = request.http.headers.bearerAuthorization else {
throw Abort(.unauthorized, reason: "Missing token")
}
guard bearerAuthorization.token == secret else {
throw Abort(.unauthorized, reason: "Wrong token")
}
return try next.respond(to: request)
}
}
extension SecretMiddleware: ServiceType {
static func makeService(for worker: Container) throws -> SecretMiddleware {
let secret: String
switch worker.environment {
case .development:
secret = "foo"
default:
guard let envSecret = Environment.get("SECRET") else {
let reason = "No SECRET set on environment."
throw Abort(.internalServerError, reason: reason)
}
secret = envSecret
}
return SecretMiddleware(secret: secret)
}
}
answered Jan 20 at 19:18
CarlosCarlos
612923
answered Jan 20 at 19:18
CarlosCarlos
612923
answered Jan 20 at 19:18
CarlosCarlos
612923
answered Jan 20 at 19:18
CarlosCarlos
612923
612923
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53453913%2fusing-api-key-in-vapor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
